freeipmi-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Freeipmi-devel] Re: [llnl-devel] More FreeIPMI Changes + Issues to Cont


From: Albert Chu
Subject: [Freeipmi-devel] Re: [llnl-devel] More FreeIPMI Changes + Issues to Contend with
Date: Mon, 17 Nov 2003 09:04:19 -0800

> In terms of sticking to a particular version of
> automake/autoconf/libtool, I would like to keep them compatible with
> multiple versions.

Ok, I suppose we can just clean up the build scripts later on then.  

> [Refer to Appendix A of IPMI 1.5 spec]

Thanks for pointing this out, I actually had never seen this before.  

> Session Approach
> ================
> ipmi-recvfrom will receive these packets into a pool of IPMI packets

So the user is responsible for retrying packets in this approach?

> Call-back approach:

Would libfreeipmi retry packets for the user then??

> Daemon approach:

I don't like this idea.  This seems like something that could be written
around FreeIPMI.  Perhaps we could do this later on as a sub-project of
FreeIPMI??

> Session Helper calls:
> libfreeipmi will provide helper calls to implement session tracking
> and let the application own the control.

This seems like the best to me, giving the users some helper functions
to deal with session control, but never actually requiring
them to use the functions.  

Are you suggesting a number of functions like the below??

ipmi_sendto_and_recvfrom(fd, ipmi_pkt, ipmi_pkt_len, ipmi_pkt_recv,
ipmi_pkt_recv_len, retry_timeout, retry_max_times);

ipmi_recvfrom_ignore_packets(fd, ipmi_pkt, ipmi_pkt_len,
IPMI_IGNORE_OLDPACKETS | IPMI_IGNORE_BAD_LENGTH_PACKETS |
IPMI_IGNORE_SOMETHING_SOMETHING);

Perhaps a set up functions that pass around a structure similar to the
one in Appendix A??

Could you perhaps give me some pseudo-code ideas of what you are
thinking about?? Then maybe we can iterate on those ...  

> But why not ignore everything that doesn't match the last sent
> command. [ THIS IS WHAT YOU ARE TALKING ABOUT ]

Agh, I should have mentioned that ipmipower is lock-step with ipmi
packets, so I automatically throw out anything I'm not expecting.  So of
course my approach is not suitable for overall use.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratories







reply via email to

[Prev in Thread] Current Thread [Next in Thread]