[Freeipmi-devel] Re: [llnl-devel] Sounds good ... I'll start adding the packet dump functions into a new

[Anand Babu]

Ben Woodard <address@hidden> writes:
>AB, I think that the big difference here is we tend to look at IPMI as a
>network protocol which also can be run locally and from talking to Al
>about the API changes that you have been making, it seems like you view
>IPMI as something that is primarily run locally but which can sometimes
>be run over the network.

Not at all. Packet are formated differently before they are
transmitted through network LAN or local KCS/SMIC.

The changes I did recently are about sharing a common code base
between these different interfaces.

>More correctly:
>- Oversimplistic
>- Compiler dependent
>- Indicative of inexperienced programmers who haven't fixed numerous
>bugs in software that has been ported around from arch to arch.
>
>First of all most experienced network programmers prefer it because they
>have been bitten by those kinds of oversimplifications too many times.
>Therefore, your assertion that nobody likes it is patently wrong. This
>morning over coffee we did a sort of ad-hoc poll of all the systems
>programmers that happened to be there. 6 out of 6 of us all consider the
>additional step of marshaling the packet before it is sent over the
>network rather than simply writing the structure out to a packet
>mandatory. 
>
>Second, the argument that the code is unreadable is simply a function of
>how well you write the code. If you write the code in a way that it is 
>unreadable, then it will be unreadable. If you are careful to write code
>that is reasonable then it will be readable.
>
>One way to keep the code really clean and readable is to make sure that
>you only marshal right before you send it out on the wire and
>immediately after you pick it up off of the wire. So 99% of the time you
>are working with the normal structures and then just before you send it,
>you marshal a packet from the structures.

>The very obvious example is if someone compiles freeipmi on a sparc
>station or a AIX box or any big endian machine then tries to send a
>packet from that machine to an ia64 box to shut it down using ipmi
>power. In the real world SA's run on who knows what and they are
>controlling a variety of different machines. 
>
>Right here at the lab we have SAs which work from their Mac laptops.
>
>Even with #pragma pack(1) the compiler can:
>1) ignore the pragma if it wants.
>2) reorder the members of a structure
>3) reorder the arrangement of the bit fields
>

There is a big confusion. 
I don't think we have byte order conversion "endian issues" problem.

Communication is always between a BMC and a remote console and not
between two applications running on different hosts.

It is very clear IPMI is little endian and RMCP is big endian.
Almost all fields are 1 byte or less than 1 byte. They will not have
byte order conversion problem. 

Very few fields are of double word length and are clearly marked
as little endian. We can always ensure the byte order of those fields.