[Port-solaris] sol11 AFS syscall

Frank Batschulat frank.batschulat@oracle.com
Tue, 23 Nov 2010 20:54:08 +0100


On Tue, 23 Nov 2010 20:18:10 +0100, Andrew Deason <adeason@sinenomine.net>  
wrote:

> I think since around Solaris 8, the OpenAFS (and I assume IBM AFS)
> client has been using syscall number 65 on Solaris. Apparently, the
> recent Solaris 11 Express release has revoked that, since syscall 65 is
> being used by unlinkat. This is made a little more annoying since we
> have been using 65 for OpenSolaris, and Solaris 11 and OpenSolaris have
> the same OpenAFS sysname and syscall number (though that can be changed,
> of course).
>
> But in any case, what should we be using going forward? If anyone on
> this list could point me/us towards somewhere that would be useful in
> (officially or unofficially) reserving a syscall number or us, or even
> reclaiming 65 (if that's even possible), it would be helpful.

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

syscall numbers are an undocumented / uncommitted interface.

We do not support 3rd-party system calls and we never have.
You are, as an ISV, on your own when you want that, and you have to
face that you're using an uncommitted interface and breakage (by a kernel  
patch) may occur.
We do not notify 3rd-party people if something in the system call table  
changes. It's not a
stable interface.

Fwiw, the UNIX ABI does not contain information how the
system call interfaces work. It is formally not documented. What is
documented is the libc interface layer, the (2) manpage section.

The only supported / documented way is to use a driver's ioctl, not a  
syscall.

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)

A bit more technical view:

1. The only authoritative resource whether a system call number is in use
    is the _Kernel's_ "sysent[]" table.
    In mdb, you can do:

	sysent::array | ::print struct sysent sy_callc

    The "nosys" ones are free - on _that particular running_ kernel only,  
strictly spoken.

2. /etc/name_to_sysnum is not used by anything except dtrace / truss to
    map names (strings) to numbers. The system call table is not initalized
    from what's in there, it's statically compiled into the kernel.
    There's no guarantee that /etc/name_to_sysnum is up-to-date.

-- 
frankB

Solaris Core OS Development, Zones Team