[Top][All Lists]
[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>