[RFC] docs: Specify V3 of the mbox protocol

Andrew Jeffery andrew at aj.id.au
Tue Sep 19 17:22:10 AEST 2017


On Tue, 2017-09-19 at 14:45 +1000, Suraj Jitindar Singh wrote:
> @wak:
> 
> As per Andrews suggestion below, how do you feel about making the first
> arg in the response for get flash name the length?
> 
> @andrew:
> 
> Since your comments regarding flash integrity aren't really relevant at
> the protocol level do you think it's something which needs to be
> mentioned in this document or is just common sense (unless you're me
> and didn't implement it that way :p)...
> 

I'd say that the fact that you didn't implement it off the bat means
that others won't either, so I think it deserves some attention.

If we choose to do a host alert on the BMC detecting an error then that
obviously needs to be specified here.

But winding back a bit, I'd suggest it's important to *specify* flash
integrity, even though the spec shouldn't enforce a particular
implementation. It should be enough to say something like:

    CREATE_{READ,WRITE}_WINDOW must provide a window containing data
    that is known to represent the state of the flash at the time the
    window is opened.

Maybe we need to make provisions for implementation suggestions in the
spec as well. I might do some reading around to see what other specs do
in this regard.

Cheers,

Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: This is a digitally signed message part
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20170919/e2555687/attachment.sig>


More information about the openbmc mailing list