On Thu, 2008-06-12 at 12:40 +0530, [EMAIL PROTECTED] wrote: > Hi Carol, > > Please find my comments below > > ********************************************** > 12) Harshad Prabhu sent in 4 patches on 7/10/07. The two for ipmi.h > and ipmi_strings.c are in cvs (he sent them in separately on 8/2/07) > but > the open.c and ipmi_sol.c patches aren't in yet. > > http://sourceforge.net/mailarchive/forum.php?forum_name=ipmitool-devel&max_rows=25&style=nested&viewmonth=200707&viewday=10 > > My comments: Regarding the open.c patch, I believe the patch is > adding > support for a special case which could potentially break things for > more > general cases. I feel like there should be a better way to accomplish > the intended goal? Regarding the ipmi_sol.c patch, it adds retries > before giving up. If that would help provide more network > latency/fault > tolerance in SOL, it sounds like it might be a good idea at first > glance > but maybe other folks have looked into this more and have a different > opinion? > ********************************************** > > > 1) Open.c patch was very much required for firmware upgrade via KCS > interface because when we are using KCS to do the HPM upgrade we get > 0x80 which is a valid completion code (HPMFWUPG_COMMAND_IN_PROGRESS) > where the return response values are important (which cannot be > ignored).The earlier code checks the completion code and if its not > ZERO does not copy any response data so the upper layer does not get > the required information. So rather then checking just the completion > code we check the return data length and copy the contents. Hopefully > this should not break anything. > *** If we are doing HPM FIRMWARE UPGRADE VIA KCS then this is VERY > MUCH REQUIRED as HpmfwupgUploadFirmwareBlock function returns VALID > response data even when the completion code is 0x80. > Hi Harshad,
Thank you very much for your response (despite the fact that it looks like I mistyped your old address (sorry about that :-}. I took a look at the spec for some guidance on this and found what appears to be some grounds for returning response information following receipt of a non-zero completion code. According to some text in 5.3.1 this behavior is atypical but doesn't seem to be necessarily illegal. Are there any other commands which would want to get response data back when they receive a non-zero completion code? Does anyone have more information on the correctness/legality of returning response data on non-0x00 CCs? I can think of four possible solutions off the top of my head (none necessarily acceptable/workable :-}: 1) always return response data if it's available (as your patch does). 2) Upon receiving a non-zero completion code (only), check the specific command and completion code for this special case and return response data. However, this adds a bit of overhead to all failure cases and smacks of being a fairly gross hack but otherwise leaves the current functionality unchanged for all other cases. 3) HPM could define its own interface with its own open routine. (Haven't looked into whether this is workable or what the ramifications would be outside of some duplicated code.) 4) Use a raw command for the HPM command(s) that require different behavior. Anyway, I hope some other folks will respond with comments. And thank you very much for all your patches and your continued interest in ipmitool! :-) ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
