,----[ 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 [email protected] http://lists.gnu.org/mailman/listinfo/freeipmi-devel
