Howdy everyone, > The plan is to commit one more tool (ipmi-fru) into FreeIPMI before > releasing 0.4.0-beta. The tool has been complete for quite some time, > however I have not received GPL approval from my organization (it > normally doesn't take this long, not sure why it's hung up) to release > it into FreeIPMI publically.
It seems that the GPL approval for ipmi-fru may be delayed for quite some time. So, barring some miracle approval over the remainder of the week, I am going to give up on ipmi-fru for FreeIPMI 0.4.0. The 0.4.0 beta should be out in early July. Al On Thu, 2007-06-21 at 13:06 -0700, Al Chu wrote: > Just thought I'd send some notes + updates. > > The plan is to commit one more tool (ipmi-fru) into FreeIPMI before > releasing 0.4.0-beta. The tool has been complete for quite some time, > however I have not received GPL approval from my organization (it > normally doesn't take this long, not sure why it's hung up) to release > it into FreeIPMI publically. > > I had planned to release the 0.4.0 beta in early July. Hopefully I get > GPL approval soon and we can still release around that time. > > I looked into and actually began development of IPMI 2.0 protocol > support into UDM so it could be supported in most of the FreeIPMI tools > (i.e. ipmi-sensors, ipmi-sel, etc.). However, after a half a day of > effort, I have now abandoned it for the 0.4.0 release. The way that UDM > is architected makes it quite difficult to implement. > > In essence, the issue lies in the implementation of > ipmi_lan_open_session() and how it calls other UDM functions (i.e. > ipmi_cmd_set_session_privilege()) before UDM is setup and has completed > for the user. Due to the nature of the IPMI 1.5 protocol, these issues > could be worked around relatively easily. > > However, w/ IPMI 2.0, the above architecture becomes far more difficult > to workaround. Ipmi_lan_open_session() should be re-written to not use > any other UDM functions. > > A.B., is someone on the Z-research staff (perhaps Ragha) interested in > re-architecting this? I could do the subsequent IPMI 2.0 support > afterwards? I still need to think a bit more about the code > architecture before we do it. > > Al > -- Albert Chu [EMAIL PROTECTED] 925-422-5311 Computer Scientist High Performance Systems Division Lawrence Livermore National Laboratory _______________________________________________ Freeipmi-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
