[Skiboot] [PATCH v2 4/5] external/opal-prd: Support manufacturing command HTMGT and attribute override
patrick at stwcx.xyz
Wed Aug 26 04:37:15 AEST 2015
On Tue, Aug 25, 2015 at 12:45:08PM +0800, Jeremy Kerr wrote:
> Hi Patrick,
> >> Since we don't have interface version changes here, you'll need to
> >> consume part of this reserved array if you add functions to the
> >> runtime_interfaces struct.
> > That's not true. We purposefully have a big enough reserve that we are
> > fine with NULL pointers between any two reasonable levels of Hostboot
> > and Skiboot. We're not going to add 32 functions between two levels we
> > need common support between.
> I don't understand why you wouldn't want to put these new pointers into
> the previously-reserved area. Not doing so changes the size of the
> struct shared between HBRT and opal-prd, which doesn't seem like a great
> idea to me. Even if we do have fewer than 32 additions, we'd still be
> accessing areas outside of the struct when running with an older HBRT.
> Although this will *probably* behave okay for the foreseeable future,
> we're dealing with distros that have 10+ years until EoL.
The Hostboot version of this file says the following:
// 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.
Is there a reason why this file isn't just copied verbatim from
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Skiboot