[Freeipmi-devel] Re: [llnl-devel] FreeIPMI conflict/issue list

[Anand Babu]

,---- Albert Chu <address@hidden> writes:
| Ben Woodard has far more experience in this area than me, b/c he worked
| on porting/fixing lpd for a number of years.  But he suggests something
| along the lines of:
| 
| marshall_ipmi_pkt(ipmi_pkt *pkt, char *buf, int buflen) {
|    memcpy(&buf[0], pkt->char_val, 1);
|    memcpy(&buf[1], to_little_endian(pkt->int_val), 4);
|    memcpy(&buf[5], pkt->netfn << 2 | pkt->lun, 1);
| }
| 
| Unmarshalling would be the opposite, putting values into the appropriate
| fields.  Its painful and mind numbing to code, but several developers
| agree that it must be done to avoid problems down the road.
`----

Problem:
We cannot have a generic marshall and un-marshall function. 
Instead we need to write one for every IPMI rq/rs call. We currently
have one call per rq and rs automatically gets filled in the rs
struct. 

Writing 2 calls for every IPMI cmd is not a problem. My biggest worry
is difficulty in debugging. Right now I just use gdb and see the
contents meaningfully just before I call ipmi_sendto or ipmi_recvfrom.
:(


,----
| I found yet another reason to do the marshalling and unmarshalling.
| 
| struct foo {
|    int a: 2;
|    int b: 6;
| };
| 
| On some compilers/machines/whatever foo's will be aligned "a:b" in
| memory, while others align it "b:a" ... 
`----

Ahhh, this sucks. May be we can use specific compiler switches or
#ifdef them. 

BUT

Correctness of implementation is much more important than ease of
coding. If marshalling/un-marshalling will address porting issues, we
will have to do that.

Let us get concrete proof where this approach will fail and how
frequently we will hit them. This will give us a clear picture of when
and what to compromise. We will take Ben's advice too.

After I check-in the inband user-space IPMI driver, we will have a
complete platform neutral IPMI solution. So lets take this porting
issue seriously.

Happy Hacking,
-ab