Re: [Freeipmi-devel] ipmi_lan_open_session() question

[Albert Chu]

AB,

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

Perhaps you can tell us what functions you imagine may be dropped. 

> I seriously recommend everyone to use the Unified Driver Model (UDM)
> interface. It has numerous enhancements

AB, I'm not doubting that it has a number of enhancements.  However,
with all APIs, as you abstract away details you remove flexibility from
the programmer.  For example, the strength of ipmipower is its protocol
parallelism.  Its protocol parallelism comes from its "manual"
management of the ipmi protocol across all nodes.  How can I still
achieve the performance of the old ipmipower if ipmipower is forced to
move to the UDM?

Another example.  You assume in the UDM that users are willing to block
on a recvfrom() waiting for a reply from an IPMI cmd request.  What if a
user doesn't want this??

I think if you can let us know what API functions may or may not
disappear, that would help things alot.  I just don't believe its
correct to just assume that the UDM will be better than what currently
exists.

Al

--
Albert Chu
address@hidden
Lawrence Livermore National Laboratory

----- Original Message -----
From: address@hidden, Anand Babu <address@hidden>
Date: Thursday, September 29, 2005 6:31 pm
Subject: Re: [Freeipmi-devel] ipmi_lan_open_session() question

> ,----[ 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]  
>