[Port-solaris] sol11 AFS syscall

[Jeffrey Hutzelman]

--On Tuesday, November 23, 2010 08:54:08 PM +0100 Frank Batschulat 
<frank.batschulat@oracle.com> wrote:

> Andrew, there's not really an "offical" way ro reserve or even reclaim a
> syscall number.

Sure there is.  If it's an interface, there can be a contract for it, no?

> There could be made an exception, if that 3rd party would request an
> interface contract for a stable Solaris system call number offically from
> Oracle via
> the appropriate ISV channels that we'd agree upon. (I don't know of any
> ever happened though)

Back in the days when AFS was an IBM product and not yet an open-source 
software project, they had this problem a couple of times, which resulted 
in AFS's syscall number changing between Solaris releases (because they 
were essentially "stealing" a number and counting on it to remain unused). 
It looks like they used 105 from SunOS 5.1 through 5.6, 73 in Solaris 7, 
and 65 since Solaris 8.

Our understanding was that, at the time of the Solaris 8 port (again, 
before this code passed into our hands), developers at IBM made appropriate 
arrangements for syscall 65 to be reserved so as to avoid the need for 
future changes.  Sadly, I now suspect this never took the form of a formal 
interface contract, leading to the present situation.


FWIW, it seems that syscall 65 was reallocated, along with a number of 
other numbers marked "reserved", as part of PSARC/2009/657, which in turn 
was opened apparently in response to bugid 6906485.  The mail for that case 
contains a fair amount of discussion on existing syscall traps to be 
removed or emulated in terms of other calls, as well as breaking out 
subcodes of fsat into separate top-level syscall opcodes.  However, it 
contains no indication that this would be accomplished by reallocating 
numbers previously marked "reserved".

Ideally, we'd like to see 65 reverted to its "reserved" state (moving 
unlinkat to another number), preferably with an appropriate comment 
indicating that it is used by OpenAFS.  Of course, as you note, the best 
way to make sure it stays that way would be to actually establish a 
contract protecting this interface.  For those reading who may not know how 
this works, this would not necessarily prevent the number from ever being 
reused, but it would give us advance notice and an opportunity to object.

I'd suggest also reverting 64 and 66..69 to "reserved" state, and 
allocating new numbers for the other fsat subcodes which were assigned 
there.  However, that doesn't affect OpenAFS and I don't know what, if any, 
other users there were of those numbers.

Frank, if you have some other approach to suggest, feel free.  Bear in mind 
that for us, the AFS system call (or at least, some subcodes, including PAG 
management, token management, and pioctl()) _is_ an interface, and there is 
code outside OpenAFS which uses it.  So, while a change is possible, it's 
slow and a bit painful and thus something we'd prefer to avoid.

-- Jeff