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

[Albert Chu]

Whenever you get a model/pre-code thingie put together, just send it to
me.  Atleast we can begin iterating and discussing things, I don't want
to wait for savannah anymore.  Then we can discuss what needs to be done
still and what work to divide up.  

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: Anand Babu <address@hidden>
Date: Monday, December 8, 2003 4:42 pm
Subject: Re: [Freeipmi-devel] libfreeipmi struct/pack(1) vs byte array

> 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>
>