freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] Re: Marshall/Unmarshalling talk


From: Anand Babu
Subject: [Freeipmi-devel] Re: Marshall/Unmarshalling talk
Date: Thu, 04 Dec 2003 17:04:24 -0800
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.3 (gnu/linux)

,---- Albert Chu <address@hidden> writes:
| > Nobody likes the "byte array" model. Code is utterly unreadable. 
| > But when portability is #1 goal, there is no choice.
| 
| It is only unreadable after you marshall it.  The idea is:
| 
| ipmi_pkt_create(&pkt);
| printf("foo = %d\n", pkt.foo);
| // Do whatever your heart desires with pkt
| length = marshall_pkt(&pkt, buffer, buflen);
| sendto(fd, buffer, length);
| 
| The packet is still 100% readable/editable until just the moment
| it is sent on the network.
`----
My initial understanding was, we will never use C structures are
all. Every header and command will be packed using bit-wise operators
and macros.

If we can marshal the data just before dropping the packet to network,
is a is a no-brainer. We should simply go ahead and implement it.

My doubt is,
marshall_pkt() will have no knowledge of member indices and bit fields
to pack them to a byte array.

,----
| Right now, FreeIPMI will be 100% guaranteed to break if:
| 
| A) A compiler does not support #pragma pack(1)
|    - But this is probably rare and only on older machines which
|      don't support IPMI.
`----

Other popular compilers don't support "#pragma pack or equivalent" ?

,----
|    - In addition, if your compiler doesn't support byte alignment
|      in structures.  i.e.
| 
|      struct foobar {
|          u_int8_t foo:4; 
|          u_int8_t bar:4;
|      };
`----
You mean bit fields?

,----
| B) A processor is big-endian
|    - Is it reasonable to assume IBM or Apple (maye Sun, I can't 
|      remember) will never use IPMI??
|    - Itaniums can be Big or Little Endian.  Is it reasonable to
|      assume users will always have itaniums in little endian mode??
|      People do wierd things ... 
`----
I don't think we have Endian issues here.

It is very clear that RMCP is big-endian and IPMI is little-endian.

Only few fields like session-id, initial-inbound-seq-num are of word
or double word length and are clearly marked by IPMI spec. We should
always have macros around them.

What we are suffering form is byte-alignment issue. How compilers are
packing struct members.

,----
| C) A compiler aligns data in their structures differently
|    - There is no guarantee that any compiler will align the data
|      exactly like we want it.  
|    - There is no guarantee GCC will continue to align the data
|      exactly like we want it.
`----
As long as members are aligned to single byte "#pragma pack(1)", we
will be guaranteed about the gcc struct member alignment.

,----
| Obviously, what we choose to do depends on the goals of FreeIPMI.  We
| (LLNL) would personally like to see it become a library that everyone
| out there loves and uses.  Non-portability means some developers may
| decide not to go with it.  
| 
| Perhaps Bryan could enlighten us with Intel's goals on IPMI.  Are you
| guys going to push this hard onto all vendors??  Does Intel want
| everyone to adopt this??  I haven't the slightest idea ...
`----

SuperMirco, Tyan and many have already implemented IPMI on their
motherboards. Even AMD chose IPMI for its x86-64 architecture. So
there is no doubt about IPMI's future.

Portability is definitely one of the prime goal for this
project. Question is how to address the portability issue.

- can we manage with struct, autoconf checks and macors
or
- sure shot approach "byte array"

-- 
Anand Babu
CaliforniaDigital.com
Office# +1-510-687-7045
Cell# +1-510-396-0717
Home# +1-510-894-0586

Free as in Freedom <www.gnu.org>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]