Date:	Mon, 28 Apr 2008 17:29:07 +0200
From:	"Michael Kerrisk" <mtk.manpages@...glemail.com>
To:	"Ulrich Drepper" <drepper@...hat.com>
Cc:	"Michael Kerrisk" <mtk.manpages@...il.com>,
	"Alan Cox" <alan@...rguk.ukuu.org.uk>,
	linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
	akpm@...ux-foundation.org, torvalds@...ux-foundation.org
Subject: Re: [PATCH] paccept, socket, socketpair w/flags

On Mon, Apr 28, 2008 at 5:13 PM, Ulrich Drepper <drepper@...hat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Michael Kerrisk wrote:
> > 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?
>
> If the range of the existing parameter can indeed be restricted as
> needed for the flags it is the better approach for programmers since all
> that is needed for a programmer to do is to write
>
>
>   fd = socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, 0);
>   if (fd == -1 && errno == EINVAL)
>     {
>       fd = socket(PF_INET, SOCK_STREAM, 0);
>       if (fd != -1)
>         fcntl(fd, F_SETFD, FD_CLOEXEC);
>     }
>
> No autoconf code needed to detect the presence of a new function.  You
> can even imagine that convenience libraries will do the above
> automatically (not libc, though, where you want to recognize this
> situation).

Okay -- makes sense.

> > 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
>
> Use O_CLOEXEC, normal filesystem operation.

What happens come the day that we want to have a flag that is specific
to, say, pipe2()?  Will it be a new O_ flag? or a new PIPE_ flag?

> > inotify_init2() -- to be determined
>
> New flag.
>
>
> > 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?
>
> Yes, they are all related interfaces.  Using the same name indicates
> similarity.

Sorry -- I still don't get this -- how is it guaranteed that these
syscalls will always use the same set of flags?  For example, I could
imagine that one day, we might want a flag that is specific to
paccept() -- you seem to be saying that would never be the case?

> And just to complicate things even more:
>
> if we'd go with sys_indirect we can have single way to specify
> close-on-exec for all syscalls.  That would be at the syscall level.  At
> the API level we'd still need separate names and possibly values.

Yes.

-- 
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Found a bug? http://www.kernel.org/doc/man-pages/reporting_bugs.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists