> Date: Thu, 03 Dec 2009 00:30:10 -0800
> From: Mike Shapiro <mws at sun.com>
> Subject: Re: delete obsolete system call traps [PSARC/2009/657]
> To: "Roger A. Faulkner" <Roger.Faulkner at sun.com>
> Cc: psarc-ext at sac.sfbay.sun.com, Bart.Smaalders at sun.com,
Bryan.Cantrill at sun.com, Michael.Shapiro at sun.com, Darrin.Johnson at sun.com
>
> I certainly agree some of this is implementation and doesn't matter.
> And from a technical perspective, because the current DTrace syscall
> provider advertises the sysent table names and not the sub-coded man
> page (2) view of system calls (something we intend to rectify
> someday), we marked those names as Private in our stability mechanism.
Wise. The system call trap interfaces are certainly unstable.
The users of dtrace must already know this.
> But from a practical perspective, I'm very uncomfortable with the *at
> part of this project, whereby extremely well-known fundamental names
> used extensively by users of DTrace based on long-standing
> fundamentals like syscall::open:entry just go away, essentially for no
> benefit. (That is, we don't actually have any pressing need to add 74
> new system calls to the OS, to make use of this vast slot reclaiming)
> It just spuriously breaks people's DTrace scripts for no reason, and
> makes them harder to rewrite, since the *at variants have more
> complicated flags and whatnot.
The number of freed-up sysent table entries is a red herring.
That's not the importance of the work.
> It would seem that for those, you can simply put the equivalent
> wrapper you described in the kernel, rather than libc, thereby
> achieving the same effect of just making the bugs and code exist in
> one canonical function.
The kernel wrappers are there right now.
The code for the open() system call trap in the kernel
just calls the kernel's version of openat().
You are recommending that I do nothing, not even
modify libc to use the modern/standard *at() interfaces.
> Is there any other benefit only achieved by removing those from the
> sysent table? If not, my preference would be to leave 'open' and
> friends alone for now, resolving that with kernel function calls
> instead. If we reach the point of needing the additional slot entries
> freed up by those, that work can be done along with a true man(2)-
> equivalent syscall provider.
How about truth in advertising?
Are you aware that nothing calls the fork() system call trap anymore?
The code for fork() and forkall() in libc invokes the forksys() system
call trap, even though the fork1() and forkall() system call traps are
still there in the kernel. Anyone doing:
syscall::fork1
syscall::forkall
will be puzzled that they see no forks.
Also, in the current system there are two ways to open a file:
open(path, oflags, mode)
openat(dirfd, path, oflags, mode)
(where dirfd can be AT_FDCWD to behave the same as open())
Anyone doing:
syscall::open
syscall::open64
will miss all of the opens executed via openat().
(tar, cpio, pax, rm, cp/ln/mv, nftw(), attropen(), all call openat())
And the openat() system call trap is currently a subcode of the
generalized SYS_fsat system call trap number, so you can't do:
syscall::openat
syscall::openat64
You would have do do some convoluted operation involving:
syscall::fsat*
Likewise for all of the subcodes of SYS_fsat:
* 0 - openat
* 1 - openat64
* 2 - fstatat64
* 3 - fstatat
* 4 - fchownat
* 5 - unlinkat
* 6 - futimesat
* 7 - renameat
* 8 - faccessat
My new code breaks these subcodes out into individual system call
traps and eliminates the SYS_fsat trap number, so you can do:
syscall::openat
syscall::openat64
and likewise for all of the other *at() interfaces.
Roger
