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

[Anand Babu]

If savannah doesn't come up by tomorrow, I will send you a tar ball of
IPMI KCS inband driver integrated into libfreeipmi in the new proposed
byte-array model.
-ab

Albert Chu <address@hidden> writes:
Hey AB,
>
>> I will post a libfreeipmi byte-array model reference code before I
>> begin my work, in a separate email thread.
>
Do you have an ETA on this??  Or are you trying to wait for Savannah to
be fixed??
>
Al
>
--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory
>
----- Original Message -----
From: Anand Babu <address@hidden>
Date: Friday, December 5, 2003 1:09 pm
Subject: Re: [Freeipmi-devel] libfreeipmi struct/pack(1) vs byte array
>
>> 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>
>> 
>
>

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