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

[Ben Woodard]

On Sun, 2003-11-16 at 17:40, Anand Babu wrote:
> ,---- Albert Chu <address@hidden> writes:
> | 1) I think we need to sync up on automake/autoconf/libtool packages,
> | otherwise we're going to keep on clobbering each other's
> | aclocals/Makefile.ins with various versions.  Since thunder will be
> | running RHEL3, I'd like to suggest we move to:
> |
> | automake-1.6.3-5 autoconf-2.57-3 libtool-1.4.3-6
> |
> | What do ya think?
> `----
> No body should trust the configure and other build scripts that comes
> along with CVS. Better way is to remove these scripts from CVS.

This is what is done on most open source projects. They make sure NO
generated files are actually in the CVS repository. 

> 
> You are supposed to run the ./refresh which updates these build
> scripts every time you checkout.
> 

The traditional name for this script is autogen.sh. The file usually
contains:

#!/bin/bash
aclocal
autoheader
automake --add-missing
autoconf


> I kept them in the CVS for convenience purpose. It doesn't matter at
> all if they are broken.
> 
> In terms of sticking to a particular version of
> automake/autoconf/libtool, I would like to keep them compatible with
> multiple versions.
> 
> ,----
> | 2) ipmi_recvfrom
> |
> | I have been (logically) doing the following in ipmipower
> |
> | char buffer[4096];
> | len = recvfrom(fd, buffer, 4096);
> | if (len < min_ipmi_get_channel_auth_packet_size)
> |    /* what the heck is this, ignore this packet */
> | if (len > max_ipmi_get_channel_auth_packet_size)
> |    /* what the heck is this, ignore this packet */
> |
> | The reason code like this is necessary is b/c we can retry-packets, and
> | (b/c it is UDP) packets can returned in strange orders.  For example,
> | set_privilege_level_response = 35 bytes, activate_session_response = 44
> | bytes.  Perhaps we sent several activate_session_request messages, then
> | (after finally getting a response back) we send a
> | set_privilegel_level_request and call
> | ipmi_recvfrom(set_privilege_level_response).  ipmi_recvfrom may read an
> | old activate_session response and leave 9 bytes in the socket buffer.
> |
> | Is this a user issue?  Are they responsible for passing in a huge buffer
> | and dealing with packet lengths themselves??  I dunno, I haven't thought
> | of the proper way yet, but I think we should discuss this.
> `----
> We currently do nothing about "retry". I tried it outside the
> libfreeipmi (ie from fish), but didn't like the implementation. So
> I removed it and decide to finish the IPMI specific stuff first.
> 
> Session Approach
> ================
> [Refer to Appendix A of IPMI 1.5 spec]
> 
> ipmi-recvfrom will receive these packets into a pool of IPMI packets
> and the application will pick them from there. No packets will be
> ignored, but garbaged out when the pool fills up.
> 
> Call-back approach:
> call-back structure - function ptrs to every ipmi response call.
> Library will do the session tracking and call appropriately the
> response handlers.
> 
> Session Helper calls:
> libfreeipmi will provide helper calls to implement session tracking
> and let the application own the control.
> 
> Daemon approach:
> A separate process acts as a bridge between the BMC/UDP and
> Management-APP/TCP. Application connects to this daemon over a TCP
> session and never worries about session tracking.
> 
> No Session Approach
> ===================
> Do we really need session tracking?
>  - Yes, session sequence number is the only way to connect the
>  request and response.
> 
>  But why not ignore everything that doesn't match the last sent
>  command. [ THIS IS WHAT YOU ARE TALKING ABOUT ]
> 
>  - No, if we do not run the management app across multiple routers
>    (like Intranet/Internet).
> 
> +-------------+
> | Lets debate |
> +-------------+
> --
> 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>
> 
> _______________________________________________
> llnl-devel mailing list
> address@hidden
> http://californiadigital.com/cgi-bin/mailman/listinfo/llnl-devel
-- 
Ben Woodard <address@hidden>
Red Hat Inc.