My putback of 6200896 has added an extra argument to zone_create which produces a problem for upgrade because the upgrade scripts need to call zone_create() after libc is patched but before the system is rebooted.
The plan is to add another subcall to the zone() call that will provide the version of the userland-kernel interface. on S10FCS this call will return -ENOSYS (version 0) S10U1 would return (1) and future versions might return higher numbers as the interface is extended.
The zone_create() call in libc will be modified to check which version of the zone interface the kernel is using and mangle arguments as needed. It is my understanding that this libC stub will only need to be able to convert backwards for at most one minor release. This should keep its complexity under control.
I'm taking this over from David, as he's busy, and changing the scope
slightly; we don't need to actually mangle the arguments to
zone_create() in the onnv-gate. We only need to do that in the
patch gate deliverables.
So this RFE is pretty limited in scope-- add a new system call subcode,
ZONE_VERSION, which takes an 'int *' and fills it in with the kernel's
notion of the API version; since we've already revved the API since S10,
we're at "logical" version 2, and so we'll report 2 in the onnv gate.
For good measure I will also add a libc interface which allows libc
programmers to easily query the version; it's also possible that future
changes could need special handling in zoneadmd, so I am proposing to
tentatively expose the API as well.