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

[Albert Chu]

> Should libfreeipmi include higher level calls?

I was hoping for higher level calls / macros.  I would think libfreeipmi
should hide a lot of the internal IPMI packet structure details. I
suppose this is evolving down into a style issue.  Perhaps we could
just have a number of macros like so??

#define ipmi_pkt_check_completion_code(pkt,y)   \
         ((pkt->foo->foo->completion_code == y) ? 1 : 0)

> Usually different applications would prefer to print in different
> style. May be GTK or console interface. It is best to just return the
> error string to user and then let him decide how to print. 

I agree on this point.

When I was speaking of packet perror fuctions, I was meaning more like this:

void ipmi_pkt_perror(ipmi_pkt * pkt, char *str) {

  fprintf(stderr, "%s: session id:    %x\n", str, pkt->sess->sess_id);
  fprintf(stderr, "%s: foo:           %x\n", str, pkt->foo);
  etc. 
  etc.
}

I feel that a packet dump set of functions is vital for the library.  I
have a set of these functions in my library, and they were vital to my
debugging of ipmipower.  

> We can write a simple macro around this. Because the structs are
> consistent across the code and the command specific fields 
> are abstracted with known block names, it should work.

This is exactly what I did in my library ...

> Both of these macros exist in libfreeipmi/src/ipmi-msg-support-cmds.h.
> Username is required for ipmi_get_session_challenge_rq and 
> challenge_str for ipmi_get_session_challenge_rs.

  Yes, but not in activate_session_rq ... its just a typo on your part.  
  I probably shouldn't have even mentioned it, just should have changed 
  it :-)

  if (challenge_str)
    {
      memcpy (activate_session_rq->data.challenge_str,
              challenge_str,
              IPMI_SESSION_MAX_USERNAME_LEN);
    }

> Help me understand which approach will do the job.

For the short term, what is there is fine.  But I believe the long term
solution must be a set of marshal and unmarshall functions.  The marshal
and unmarshal functions will take care of the #pragma problem, as well
as any future compiler and endian problems.

> Another change is to move the chassis control related code to
> src/ipmi-chassis-cmd.{c, h} from ipmi-msg-support-cmds.c

I was hoping for that too ...
 
I am still having issues with subversions.gnu.org's stupid SSH rsa key
thingie.  I was finally able to checkout code with my savannah username,
but it stopped working this morning.  Once I get that sorted out, I will
begin making changes ... 

Al