Audet, Jean-Michel wrote: > Corey wrote: > >> ipmitool will need modifications to handle it, though >> > > I am not sure about the required modification. As specified, this is working > just fine now. As you mention, a lot of functionality is handle by FRU 0 but > as you mentioned also, the upgrade commands are only available directly. > This is a major feature and probably *THE* main reason for this dual bridge > implementation. This is a strong requirement from our customer. > Maybe the modifications are already there. IIRC, I saw something about FW upgrade, so maybe it's done. > Corey wrote: > >> IMHO, this should work as something "special" in ipmitool. >> > > > I don't agree that this should be set as something special. What is the > problem of leaving that as standard (without any special compiling switch I > suppose?). > I was thinking the wrong way about this; with ipmitool all this needs to be is another addressing mechanism. What you wouldn't want is something like OpenIPMI scanning behind the IPMCs when all the sensors are already there in the IPMC. But for ipmitool it wouldn't matter.
-corey ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Ipmitool-devel mailing list Ipmitool-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ipmitool-devel
