,----[ Albert Chu <[EMAIL PROTECTED]> ]
| 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?
Only those who wants to develop tools that needs to work both inband
and outband seamlessly has to use UDM. Otherwise you are free to
access any APIs at any layer. Only the redundant obsolete APIs are
removed. UDM is not completely ready yet to accommodate all
needs. Protocol parallelism should be achievable thru UDM
too. Performance difference will not even be noticeable. I am planning
to inline the calls.  

,----[ Albert Chu <[EMAIL PROTECTED]> ]
| 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??
UDM APIs will support non-blocking calls too. During UDM open call,
you pass this option.

,----[ Albert Chu <[EMAIL PROTECTED]> ]
| 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.
If you notice, certain new functions will be prefixed with 2. Only
those calls will be replaced. I will rename the old calls with new
name or using a macro like FREEIPMI_FORCE_0_1_3_API.

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

Freeipmi-devel mailing list

Reply via email to