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

[Albert Chu]

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

> 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?? :-)

> 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

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

> If not "#pragma pack(1)", don't we have a similar directive or a
> compiler switch in other compilers that is guaranteed to do
> single-byte-alignment ?

My understanding is no, although I'm not a compiler expert.  Ben??
 
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.

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory