Re: [Freeipmi-devel] libfreeipmi struct/pack(1) vs byte array

[Anand Babu]

Albert Chu <address@hidden> writes:
>> My doubt is,
>> marshall_pkt() will have no knowledge of member indices and bit fields
>> to pack them to a byte array.
>
> This is the major downside.  Unless we go with a completely different
> structure approach, we have to program a whole bunch of "marshall" and
> "unmarshall" functions for each packet type.

Yes thats correct.

>> 1) Byte Ordering (Endianess)
>> As long as we align RMCP data to BIG-ENDIAN and IPMI data to
>> LITTLE-ENDIAN, this will not pose a problem.
>>
>> Byte ordering problem will happen only when the element is bigger than
>> a byte. We rarely use a double word element inside the structure. Most
>> of them are single byte or in bits. For the few elements we can have
>> macros to convert to the specified order.
>
> If we write macros to convert into the specified order within the
> assemble/unassemble function, aren't we just doing marshalling and
> unmarshalling?? :-)

Different kinds of computers use different conventions for the
ordering of bytes within a word.  Some computers put the MS byte
within a word first (this is called "big-endian" order), and others
put it last ("little-endian" order).

Byte ordering (order of MS and LS bytes) and Byte alignment (aligning
to 8, 16, 32, ... byte boundaries) are 2 different issues. We need to
take care of both the issues irrespective of struct or marshalling.

#pragma pack(n) or byte array model takes care of only byte alignment.

In struct model:
The data type of the member will remain as word (u_int16_t) or
dword (u_int32_t). Macros will just swap the order of LS and MS bytes
based on the platform endianess. Take a look at endian.h and
bits/endian.h

In Marshalling:
The data type is a byte array, Even words or dwords are copied byte by
byte in the order dictated by the platform endianess.


>> 2) Byte Alignment - Currently the biggest problem.
>>
>> IPMI is different. The whole spec is carefully designed to be single
>> byte aligned. If you notice the reserved members, they are actually
>> structure pads used for alignment. They can also be used for future
>> expansions.
>
> I think we're getting some terminology confused here.  When I talk about
> byte alignment problems, I'm talking about the following:
>
> #include <stdio.h>
> #include <stdlib.h>
> #include <sys/types.h>
>
> struct foo {
>   u_int8_t a: 4;
>   u_int8_t b: 4;
> };
>
> int main() {
>   char one = 1;
>   struct foo f;
>   memcpy(&f, &one, 1);
>
>   printf("a = %d b = %d\n", f.a, f.b);
> }
>
> Run on Linux IA32
> a = 1 b = 0
>
> Run on AIX PowerPC
> a = 0 b = 1

Without #pragma pack(1), I cannot predict if this is byte-alignment or
byte-ordering problem.

Can you do a sizeof (foo) under AIX and tell me?


> This is my concern.  Although we have not found instances in which
> gcc aligns in a way we don't like, we have no guarantee that gcc
> will never go the other way (or perhaps we haven't found a structure
> "pattern" in which gcc wants to align a different way).

Think of the devil, it will come.
I'm already convinced to go to byte array model.

> My proposal is to do something like the following for FreeIPMI.  Within
> the assemble_pkt function:
>
> if (first byte of cmd_buf == IPMI_GET_SESSION_CHALLENGE_CMD)
>    marshall_get_session_challenge(cmd_buf, my_buf, buflen);
> else if (first byte of cmd_buf == IPMI_SESSION_PRIVILEGE_CMD)
>    marshall_set_session_privilege(cmd_buf, my_buf, buflen);
>
> Then within marshall_foo() we something like:
>
>    memcpy_int(buf, cmd->intval);
>    memcpy_byte(buf, cmd->charval);
>    memcpy_1bit(buf, cmd->1bitval);
>
> I haven't thought about the actual coding of the above yet, but you
> probably get the idea.  We will hide endian issues within the memcpy_int
> functions.
>
> unassemble_pkt will be similar, but just opposite.

I will post a libfreeipmi byte-array model reference code before I
begin my work, in a separate email thread.

+--------------------------+
|  BYTE-ARRAY TEAM WINS    |
|  Thanks to Ben, Al, Ian. |
+--------------------------+

--
 _.|_
(_||_)
Free as in Freedom <www.gnu.org>