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

[Anand Babu]

,---- Albert Chu <address@hidden> writes:
| ,----
| | 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.
`----
Yes.

I removed  the configure, Makefile, Makefile.in ... scripts from
CVS.


,----
| ,----
| | Call-back approach:
| `----
|
| Would libfreeipmi retry packets for the user then??
`----

You will do a select on the socket and transfer control to the
libfreeipmi session tracker to call back the registered application IPMI
handlers. Callback approach is difficult for application
programmers. More prone to bugs and difficult to debug.

,----
| ,----
| | 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??
`----
Yes, it is a sub project. 

libfreeipmi will also include session helpers to assist IPMI Daemon.

  +-----------+
  |Application|(compiled with libfreeipmi)
  |    ||     |
  |-- TCP/IP--|
  |    ||     |
  |IPMI Daemon|(compiled with libfreeipmi)
  |    ||     |
  |-- UDP/UP--|
  |    ||     |
  |   BMC     |
  +-----------+


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

All we need to do is packet sequencing. We need to match request and
response. Better way to do that is to use the ipmi_rq_msg.rq.rq_seq:6
field. I suppose the same rq_seq field is copied back in the response
or this purpose.
Matching with packet size cannot be trusted.

Maintain a pool of 20 packet buffers (possible upto 2^6).

pak_id = alloc_paket_id ();
         
Send the request

ipmi_recvfrom_pool (..., pool, pak_id, ipmi_rs_msg);
  { 
     packet = pool_loopup (pak_id) 
     if packet != NULL
       return

     packet = ipmi_recvfrom (...)
     if (packet.rs.rq_seq == pak_id)
     {
        ipmi_rs_msg = packet
     }
     else
     {
        pool_allocate(packet, pak_id)
        ipmi_rs_msg = NULL
     }
  }

Retrying inside ipmi_recvfrom should not be attempted. Because if we
try a system that is not on network, We will end up waiting
retry-count * timeout. Instead the management app can increase
the timeout. 

Do we really need a pool. Why don't we just drop the mis-matched
packets and let the management app retry. [YOUR APPROACH]

We will need a pool, only if we issue multiple requests without
reading the response. But We will never need this asynchronous
approach. We prefer request and response to be connected always
[synchronous]. How ever there is one situation. In future, we will
have platform event filters. Even they can be implemented as callbacks
and will be invoked by ipmi_recvfrom internally, upon reception of PEF
packets and then it continue reading for matching packet_id/rq_seq

 ipmi_recvfrom (...)
 {
    packet = recvfrom (...)

    if (paket.type == PEF)
    {
       (*callback)()
       ipmi_recvfrom (...)
    }
 }

,----
| ,----
| | 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.
`----
Not at all. This is the fastest and easiest solution. We can
use this approach until we finish all required functionalities and
later concentrate on session handling. I still don't see a convincing
reason to maintain a pool and do session tracking. 

Just drop and retry approach (based on rq_seq) should do the job
elegantly. Later on we will add a hook into ipmi_recvfrom for PEF.


----------
I saw the Changelog, You are doing a great job Al.

I will let you add this to your task list.
1) #pragma pack(0) - at the end of each header files calling pack(1)
2) All byte order conversions (endianess) issues (remember RMCP hdr u
mentioned)

I will start freezing user-space driver. Once I finish that, we will
have a whole bunch of inband utilities.

Happy Hacking
--
Anand Babu
CaliforniaDigital.com
Office# +1-510-687-7045
Cell# +1-510-396-0717
Home# +1-510-894-0586

Free as in Freedom <www.gnu.org>