Re: openat/fstatat functions implementation

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> I still think that we should not start spreading *at() syscalls, but
>> rather have one syscall to handle them.  While it is pointless to
>> dholland, I would say it is a better structure and would probably
>> reduce some code duplication.
> Why not, it is just a matter of how a 'name' is attached to the
> kernel code.

Not quite.

I don't think anyone is arguing for a with-cwd syscall that is just a
multiplexing switch-out.  The with-cwd syscall I was imagining was one
that didn't just take a sub-syscall number to control the operation
performed, but rather took a whole standard syscall, number and
argument list, and performed it as usual.  I would not implement this
as a switch-out in the with-cwd code; I would implement it as a
re-dispatch.

You say that

> Syscall numbers aren't a restricted space,

which, while perhaps technically not true when phrased like that, is
effectively true for the purposes at hand.  However, this isn't about
saving syscall numbers; this is about eliminating cross-product
maintenance headaches.

Let's consider the way which implements the *at() calls as separate
syscalls.  We need a new syscall for each standard call which takes a
pathname (well, which takes a pathname and for which we want this
capability).

Now, consider what happens when we want to do the same for, say, the
umask, rather than the working directory.  We need a new with-umask
call for each affected call, _including_ the with-cwd variants.

Now consider adding, say, with-setrusage capability, or with-setreuid,
or another one.  This means another doubling.

With "prefix" syscalls, each new "with" capability means one more
syscall, not another axis for the cross product to explode along.  (The
with call I suggested upthread actually pushes the additional stuff out
of the syscall number space into a newly-created space, but there's no
need for that; arguably it's unnecessarily elaborate.)

Yes, we won't run out of syscall numbers - not even with the
combinatorial explasion, not until we get something like 25 different
"with" capabilities (which seems unlikely).  But the cross product of
them all becomes awkward to maintain long before that:

open
open_with_cwd
open_with_umask
open_with_cwd_umask
open_with_setreuid
open_with_setreuid_cwd
open_with_setreuid_umask
open_with_setreuid_cwd_umask
open_with_setregid
open_with_setregid_cwd
open_with_setregid_umask
open_with_setregid_cwd_umask
open_with_setregid_setreuid
open_with_setregid_setreuid_cwd
open_with_setregid_setreuid_umask
open_with_setregid_setreuid_cwd_umask

Repeat for each affected call, doubling for each relevant capability
(and which calls are affected will vary from capability to capability;
we don't need, for example, readlink_with_umask(), though
open_with_umask() we do).  It rapidly becomes an unmaintainable morass.
Eliminating _that_ is what the prefix syscalls are about - indeed, if I
had to maintain the one-call-per version, I would generate the cross
products automatically in some form.

I don't see this as really any worse than __syscall().

/~\ The ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B