[Port-solaris] sol11 AFS syscall

[Douglas E. Engert]

Being a large Solaris shop and running AFS (and now OpenAFS) on Solaris
servers since 1992, I am very disappointed in this response from Oracle.
If as other have pointed out that an unlinkat could be done by accident
I would think the Oracle would look at this more closely, and do their
customers a favor and reserve syscall 65 for OpenAFS.


On 11/23/2010 1:54 PM, Frank Batschulat wrote:
> 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.
>

-- 

  Douglas E. Engert  <DEEngert@anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444