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

[Anand Babu]

Albert Chu <address@hidden> writes:
> 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

No, I think I was confused :)
Your approach is right. 

> 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??

Yes correct, Both ipmi_recvfrom and ipmi_sendto should return the 
len - rmcp_hdr.

> 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.

I meant the framework. Right now the code is all about framework. I
don't think this framework will be disturbed much. How ever I would
like to move the session headers out, like I did for rmcp_hdr. It is OK
to leave them inside for  LAN or session related cmds. But chassis and
other upcoming commands, they will be shared both by the inband
KCS/SMIC interface and LAN interface. Inband interfaces do not need
sessions. To keep them uniform across I would prefer to move session
header out all together. After that I don't fore see any more changes
to the framework (at least till ver 1 ;).


-- 
 _.|_ 
(_||_)
Free as in Freedom <www.gnu.org>