On Sat, 9 Jun 2007, Al Viro wrote:
>
> Eww... Idea of pipe(2) taking flags as argument...
Right. That was one of the patches, and it was one that I said was too
damn ugly to live.
So I instead suggested the alternate approach of adding a single new
system call that runs another system call indirectly, with a set of flags
and/or other behaviour modifications.
And I actually think that's a great idea, because we have *multiple* uses
of this kind of "run system call with special flags" issues:
- the whole "async" thing, and as Matt reminded me, this is the perfect
interface for also saying "run this system call asynchronously"
- things like FD_CLOEXEC, but also things like O_NOFOLLOW and O_NDELAY
(which currently only "open()" supports, even though it makes sense for
a lot of other ops too)
- extended flags like LOOKUP_NOSYMLINK and LOOKUP_NOMOUNT for any system
call that does path lookup (to make it return errors if you *ever*
traverse a symlink or a mount-point respectively: security conscious
programs tend to want this - think about apache that exports per-user
"public_html" stuff, but does *not* want to export /etc, and thus
doesn't like following symlinks).
> I don't know if your indirect is a good idea in that respect, actually.
> AFAICS, you are suggesting per-syscall meanings of the flags, so it really
> smells like YAMultiplexor, free for abuse.
Well, the actual _setup_ would be global (ie we would have no per-system
call actions: we'd just copy the "flags" into the thread
"system_call_flags" thing).
But yes, different system calls could decide to *interpret* the flags
differently. Quite frankly, I'd rather have that kind of overloaded flag
bitmap, than try to create something "extensible".
That said, I don't think there really will be all that many flags, and we
could even just decide that the bits have to be totally unique (and simply
limited to 32 flags). The whole point of the flags, after all, would be
things that *do* make sense for a whole group of system calls: if that's
not true, and it's some single-system-call thing, then you might as well
just always add the new system call itself!
So it makes sense for generic flags (like ASYNC and path lookup rules: not
every system call takes a path, of course, but it's conceptually still
pretty damn generic). but it wouldn't really make sense to do for a very
specific system call - it would be faster and easier to just create the
new system call in the first place.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
