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

[Anand Babu]

Albert Chu <address@hidden> writes:

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

Correct, We need to do that. Last check-in my major concentration was
on abstracting the fields abstracted within the structures. This makes
writing macros possible. You have pointed a good example. 

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

Please move those code into ipmi-errno.c. We definitely need them to
debug. We need applications to dump these session info while executing
in verbose mode. User shouldn't need gdb to report bugs.

Lets call this function ipmi_pkt_dump (ipmi_pkt * pkt, char *str)

Another problem is implementing ipmi_errno variable. How can we ensure
thread safety? Is libc errno thread safe?

>> 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);
>     }

it was a typo :D

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

Marshalling/Unmarshalling  - problem is the varying struct fields.

Do you mean - for every IPMI cmd we byte copy to generic void * byte
sequence rather than structures ?
 
> 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 ... 

It will take atleast 4 hours for the cron job to pickup after you
submit your rsa public key. My cvs seems to work. 

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