[Skiboot] [PATCH v2 4/5] external/opal-prd: Support manufacturing command HTMGT and attribute override

[Patrick Williams]

On Wed, Aug 26, 2015 at 10:24:16AM +1000, Stewart Smith wrote:
> Jeremy Kerr <jk at ozlabs.org> writes:
> >> // Reserve some space for future growth. // do NOT ever change this
> >> number, even if you add functions. // // The value of 32 was
> >> somewhat arbitrarily chosen. // // If either side modifies the
> >> interface.h file we're suppose to be able to // tolerate the other
> >> side not supporting the function yet.  The function // pointer can
> >> be NULL.  So if we require a new interface from OPAL, // like
> >> "read_iic", we need to be able to tolerate that function pointer //
> >> being NULL and do something sane (and erroring out is not consider
> >> sane). // // The purpose of this is to give us the ability to
> >> update Hostboot and // OPAL independently.  It is pretty rare that
> >> we both have function ready // at the same time.  The "reserve" is
> >> there so that the structures are // allocated with sufficient space
> >> and populated with NULL function pointers. // 32 is big enough that
> >> we should not likely add that many functions from // either
> >> direction in between any two levels of support.
> >
> > That seems like a bad way to retain ABI compatibility. Since this
> > doesn't allow any for agreement on the actual size of the struct, we
> > have no way to contain reads/writes to areas of memory that we can
> > guarantee are valid.
> 
> I tend to agree.
> 
> Having version and size members let you sort out pretty much all
> additions/removals/modifications pretty trivially.
> 

I believe it was Ben and I that originally worked this out.  The
thinking was that we only needed to change the version when an existing
API changed and that we made the structure sufficiently big enough that
any new function would just show up as a NULL to new firmware.

Changing the structure size is only a problem if we add 32 functions
between two levels we need to support.  Otherwise, neither side goes
outside the boundaries of the function.

I realize that maybe this decision was made so that we could support
initial development and was not considering long-lived support once the
userspace side gets into a distribution.

At what point is opal-prd considered "released" such that it is in an
official distribution and will require long-term support?  Are we
already past that point?  I am fine with changing our direction at that
point and starting to reduce the function pointer count as we add new
interfaces.
-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.ozlabs.org/pipermail/skiboot/attachments/20150831/d75c5a99/attachment.sig>