In-Band Firmware Update

[Ed Tanous]

>> The interface defines some primitives:
>> - BmcBlobGetCount: returns the number of blobs known presently
Is this blobs per object?  Blobs total for the system?

>> - BmcBlobEnumerate: returns the blob's name for an index into the
>> count (index 0 might return "/tmp/bmc-image" or something)
Could this be a well known name rather than an index?  Blob 0 is a lot 
less descriptive than Blob: bmc-image.

>> - BmcBlobOpen: opens the blob and returns a session for future actions
I'm not really following what blob open would do.  What arguments does 
it take?  Would this be on a higher level collection type interface?  is 
BmcBlobReset or BmcBlobClear a better name for the action it's performing?


>> - BmcBlobRead: returns bytes
>> - BmcBlobWrite: writes bytes
Should we put any restrictions on write/read sizes, or leave it up to 
each implementation to enforce?  I'm kind of leaning toward the later, 
although it makes the interface harder to use.
I'm thinking about in band updatable power supplies that can only accept 
writes of a very particular block sizes (I think it's 16 bytes at a time).

>> - BmcBlocCommit: any action the handler wants that basically means, do thing.
>> - BmcBlobClose: closes the file
What is the difference between commit and close?  Close seems like a 
possible implementation of commit, but not necessarily required if Blob 
doesn't represent a file.

>> - BmcBlobDelete: deletes the blob, not always possible.
>> - BmcBlobStat: returns blob metadata
What would this return?

>> - BmcBlobSessionStat: returns metadata specific to the session
? I don't see any other mention of session.  I feel like I'm missing 
part of the picture.

Overall, this looks really interesting.  We have a relatively similar 
interface for shipping SMBIOS and MDR data from BIOS that we had to 
invent to get those fields to work.  I'm not sure if they map 100%, but 
we could likely get it to work with a little massaging to our stuff.  As 
a general purpose interface, it seems very useful, especially in the 
context of firmware update, which could be implemented in any number of 
interfaces.

I'd be interested in separating out the "file like" nature from the 
interface, and keep it as just a "block level" update, that may be a 
file, or may be something else.

I'm also interested in the actual arguments, as well as the distinction 
between a Blob and a BlobSession that I'm not really understanding.

>>
>> It doesn't immediately define actions such as "abort", however, "close
>> without commit" might be equivalent.
I kind of like this about the interface.  Some updates can't really be 
reverted cleanly, so leaving it up to the implementation to decide 
(possibly based on a timeout or something) seems kinda nice to have.

>> Regardless if we want to use it for this, I'd also be willing to
>> upstream our ipmi-blobs handler infrastructure.  It has presently one
>> limitation, and that is that it doesn't support run-time loading of
>> handlers, how ipmid supports finding IPMI libraries.  It is fully
>> contained with the handlers, and they're enabled by configuration
>> flags in the build.  This limitation could be removed if desired.

 From the looks of Vernons IPMI handler rewrite document, runtime 
loading of handler libraries might be out anyway, so I don't think this 
is a non-starter, especially given the timeframes.