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

[Albert Chu]

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