[Freeipmi-devel] Re: [llnl-devel] checking chksums, possible framework change needed??

[Albert Chu]

Hey AB,

> Problem is not locating the chksum (we can use your last-byte
> assumption), but to calculate the chksum locally to match. This
> depends on comp_code.

I'm a little confused, what do you mean by this statement??  In my
opinion, the comp_code has nothing to do with checking the checksum.  We
can write a function/macro like so ...

ipmi_pkt_checksum(ipmi_pkt *pkt, int ipmi_received_len) {
   chksum = pkt[ipmi_received_len - 1];
   chksum2 = ipmi_chksum(&(pkt->msg.rs), ipmi_received_len - 
                         sizeof(everything before pkt->msg.rs));
            // ^^ maybe off by 1 error, but you get the idea
   return ((chksum == chksum2) ? 1 : 0);
}
 
And a user can use it like this:

len = ipmi_recvfrom(fd, &rmcp_hdr, &ipmi_pkt, sizeof(ipmi_pkt));
if (!ipmi_pkt_checksum(&ipim_pkt, len - sizeof(rmcp_hdr)))
    // yell and scream

As I said earlier, the only thing about this approach is that the user
is required to subtract the sizeof(rmcp_hdr) from the length, which I
find strange and awkward.  Instead, I think ipmi_recvfrom should return
the length of only the ipmi_pkt read, not the rmcp part.  To me, this
makes sense and makes the API call "ipmi_recvfrom" make more logical
sense.  Is there any reason to return the length of both the rmcp_hdr
and the ipmi_pkt length together??

> Between them, I will choose ipmi-utils.h. They are basically utility
> functions/macros that aid application programs. They directly do not
> implement the spec.

Ahhh, I didn't think about putting them there.  That makes sense.  I put
them in a new file ipmi-msg-specs.h, but ipmi-utils.h makes more sense.
I'll move them.

> Code is freezing now. It is good time to start writing macros before
> it gets too late. 

Do you mean freezing as in doing a release / tagging a branch??  As far
as I'm concerned, I'd like to freeze the framework sometime soon, but
I'd like to/am willing to/am happy to iterate on developing
macros/utils/extensions onto the freeipmi base for awhile. I imagine we
will discover bugs, errors, issues, important util functions, etc. that
should be fixed/added to FreeIPMI once ipmipower/bmcconfig/etc. really
get going.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratories