[lkml]   [2007]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [patch 7/8] fdmap v2 - implement sys_socket2

    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.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-06-10 01:37    [W:0.023 / U:0.588 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site