freeipmi-devel
[Top][All Lists]
Advanced

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

Re: [Freeipmi-devel] ipmi_lan_open_session() question


From: ab
Subject: Re: [Freeipmi-devel] ipmi_lan_open_session() question
Date: Thu, 29 Sep 2005 18:31:06 -0700
User-agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux)

,----[ Albert Chu <address@hidden> ]
| AB,
| >
| > libfreeipmi driver APIs will completely change in the next
| > release.
| >
| I just want to be sure that a "reasonable" backwards compatibility
| can be expected in 0.2.0.  We all have code that isn't part of
| FreeIPMI and some of the newer APIs may not be suitable/usable for
| our needs.  I know for a fact I cannot use the new sensors api at
| all.  If someone develops based out of the 0.1.3 API, I believe they
| should still be able to use the old API if it is desired.
`----
So far we have retained backward compatibility. But our plans are to
drop the old APIs as soon as all of the utilities (including external
projects) report they are ready.

I seriously recommend everyone to use the Unified Driver Model (UDM)
interface. It has numerous enhancements
 * No global variables (thread safety).
 * Unified driver interface. Internally abstracts all inband,
 outofband and probing drivers.
 * Easier and cleaner API interface, fewer number of arguments.
 * It is easy to maintain UDM APIs unchanged across future releases 
   because of its design.
 * LAN driver in UDM has serious enhancements and bug
 fixes. "per-message-auth" support will be enabled based on
 'get-channel-auth-caps' returns automatically. This will be a big
 performance improvement (fewer bytes to transfer, one time password
 encryption). 
 * Buffers re-used where ever possible through ipmi_device_t. This
 avoids unnecessary memory copying and allocation.

0.1.3 APIs impose a serious limitation if we want to move
forward. Every IPMI command needs to be written for each driver and
utilities becomes will go crazy supporting all the drivers. I can
retain the old APIs till all utilities gets ported to newer APIs. But
they will get no new enhancements. 

Coding freezing and QA releases will happen by end of October and
Final release tentatively planned around end of November. 

I wish I can drop the APIs and have a clean start from 0.2.0
onwards. Our next major focus will be towards SOL support.

-- 
Anand Babu 
GPG Key ID: 0x62E15A31
Blog [http://ab.freeshell.org]              
The GNU Operating System [http://www.gnu.org]  




reply via email to

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