lkml.org 
[lkml]   [2008]   [Apr]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] paccept, socket, socketpair w/flags
    On Mon, Apr 28, 2008 at 4:13 PM, Ulrich Drepper <drepper@redhat.com> wrote:
    > -----BEGIN PGP SIGNED MESSAGE-----
    > Hash: SHA1
    >
    > Michael Kerrisk wrote:
    > > This is ugly. Why invent a diffent set of flags here. I agree with
    > > your earlier statement that new syscalls would be cleaner.
    >
    > Don't lay words in my mouth. I do think that different flags are
    > needed.

    Okay -- to some extent I seem to have misunderstood you. I'll step
    back a little and start again.

    You have said it would be cleaner to have new syscalls for socket()
    and socketpair(). I understand your reasoning for that to be that
    doing so is cleaner than overloading the type argument of the existing
    versions of these syscalls. I agree. So, since you are adding new
    syscalls for all of the other interfaces, why not do it for these two
    syscalls also?

    > The name of the flag must indicate what it is for and you don't
    > want to mix flags with different prefixes for the same flags parameter.
    > Not introducing separate flags would mean all the functions would have
    > to accept the same set of flags which will sooner or later create
    > problems. I really don't see the problem here.
    >
    >
    > > then *please* let's go the hwole way cleanly, and have new syscalls
    > > also for socketpair() and socket(), and make all of the new syscalls
    > > use the same flags.
    >
    > Hell, no, that's worse than everything else proposed. We don't have the
    > luxury to have a separate parameter to indicate close-on-exec or not.
    > For efficiency it has to be a multi-purpose flags parameter and the
    > flags each syscall takes are different since the functionality is different.

    Okay -- I see your point (and I didn't read your patches closely
    enough). However, the rationale for the implementations proposed to
    date isn't very clear. So far we have the following new flags:

    timerfd_create() -- TFD_CLOEXEC
    signalfd4() -- SFD_CLOEXEC
    eventfd2() -- EFD_CLOEXEC
    epoll_create2() -- EPOLL_CLOEXEC
    open() (and openat()), dup3() -- all use O_CLOEXEC
    socketpair(), socket(), paccept -- all use SOCK_CLOEXEC
    pipe2() -- to be determined
    inotify_init2() -- to be determined

    It would help if you laid out your reasoning for creating distinct
    flags for some syscalls but not others. For example, is the
    assumption here that socketpair(), socket(), and paccept() will always
    use the same set of flags? If so, what makes that group special with
    respect to your arguments about the need for separate flags for each
    syscall?


    \
     
     \ /
      Last update: 2008-04-28 16:53    [W:5.394 / U:0.196 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site