Re: [PATCH] alternative to sys_indirect, part 1

Re: [PATCH] alternative to sys_indirect, part 1

[Michael Kerrisk]

On 4/24/08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > - I decided against using the O_* flags here.  Most are not useful and
>  >   we might need the bits for something else at some time.  Hence the
>  >   new SOCKFL_* flag.  The intend is to define SOCKFL_CLOEXEC and
>  >   O_CLOEXEC to the same value.  In this case there is zero overhead.
>
>
> Given we will never have 2^32 socket types, and in a sense this is part
>  of the type why not just use
>
>         socket(PF_INET, SOCK_STREAM|SOCK_CLOEXEC, ...)
>
>  that would be far far cleaner, no new syscalls on the socket side at all.

That''s not quite true.  There is still the problem of accept().

It's worth trying to summarize all of the syscalls that create file
descriptors to get a handle on how many new syscalls might really be
required.  AFAIK, the list below is all of the syscalls that create
FDs on Linux.

The following system calls all have a flags argument that either
already has a O_CLOEXEC functionality, or to which that functionality
could be added:

* open()
* openat()
* fcntl(F_DUPFD)
* timerfd_create()
* mq_open() (on Linux MQ descriptors are really just file descriptors)

For the following system calls, we could overload another argument for
the purpose:
* socket() (using the 'type' argument, as per Alan's suggestion)

The following syscalls don't have a flags argument, but does it
matter?  For each of them there is an alternative API that can be used
instead, if the functionality is required.

* dup2() -- use fcntl(F_DUPFD) instead
* dup() -- use fcntl(F_DUPFD) instead
* creat() -- use open() instead

The following system call doesn't have a flags argument, but we could
conceivably overload the existing 'fd' argument.  When creating a new
file descriptor, the 'fd' argument must be -1.  We could say that to
create a new fd, the argument must be say NEW_SIGNALFD, defined as
-MAXINT, ORed with the desired flags.

* signalfd()  (glibc API supplies a flags argument, but the syscall
doesn't have one)

The following system calls don't have a flags argument, and the only
way to solve the problem is a new syscall, or sys_indirect().

* eventfd()  (glibc API supplies a flags argument, but the syscall
doesn't have one)
* accept()
* pipe()
* inotify_init()
* epoll_create()

So the alternative to sys_indirect(), at least for the purpose of
O_CLOEXEC and similar, would be to create 5 new system calls (or six,
if one finds the signalfd() hack too ugly, which perhaps it is; or 7
if one doesn't like Alan's suggestion for socket() -- if one went the
route of new syscalls, then I'd suggest creating a new socket()-type
syscall with a flags argument).

Cheers,

Michael


-- 
I'll likely only see replies if they are CCed to mtk.manpages at gmail dot com

Re: [PATCH] alternative to sys_indirect, part 1

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Kerrisk wrote:
> * dup2() -- use fcntl(F_DUPFD) instead

Wrong.  You cannot implement dup2 with fcntl since the latter won't use
a file descriptor which is already in use.


> So the alternative to sys_indirect(), at least for the purpose of
> O_CLOEXEC and similar, would be to create 5 new system calls (or six,
> if one finds the signalfd() hack too ugly, which perhaps it is; or 7
> if one doesn't like Alan's suggestion for socket()

Without changing the socket interfaces (plural, socketpair) there would
have to be 7 new syscalls, with changing socket* to an IMO cleaner
interface 9.


Or we just add sys_indirect (which is also usable for other syscall
extensions, not just the CLOEXEC stuff) and let userlevel (i.e., me)
worry about adding new interfaces to libc.  As you can see, for the more
recent interfaces like signalfd I have already added an additional
parameter so the number of interface changes would be reduced.

Somebody please make a call and then let's go on with life.  I don't
care much either way anymore.  I do hope nobody thinks this is an issue
which can be completely ignored (see, e.g., the bug I pointed to the
other day).

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIEJ372ijCOnn/RHQRAorwAJ4u78MYFrJbPqcqW1fPae2liLxxhwCfa7e7
r2vc7FnEpzyJmqEKU6aCd5E=
=EG3n
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] alternative to sys_indirect, part 1

[Alan Cox]

> Somebody please make a call and then let's go on with life.  I don't
> care much either way anymore.  I do hope nobody thinks this is an issue
> which can be completely ignored (see, e.g., the bug I pointed to the
> other day).

Its very hard to do that without knowing what other Unixlike and POSIX OS
plan to do and if we'll end up with a third yet again different API to
support when it reaches a standards body.

We shouldn't be seeing this as a Linux problem, its a BSD problem, an AIX
problem, a Solaris problem and an HPUX problem and really wants one
solution applying across distributions or it will harm everyone in the
long term.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] alternative to sys_indirect, part 1

[Ulrich Drepper]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alan Cox wrote:
> We shouldn't be seeing this as a Linux problem, its a BSD problem, an AIX
> problem, a Solaris problem and an HPUX problem and really wants one
> solution applying across distributions or it will harm everyone in the
> long term.

Look at the other interfaces.  I've proposed them for POSIX and they are
going to be in the next revision (O_CLOEXEC, F_DUPFD_CLOEXEC).  I'm
confident that whatever we'll do will be endorsed this way.  It's just
too late for the next revision, it'd have to wait a few years until work
on the next revision (esp reviews) start.  That's too long.

- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)

iD8DBQFIEKT/2ijCOnn/RHQRAkyoAJ9/FRwN3r6zg2cSvzVrA2TiGlfergCdG1r9
H/UghrO5A99ieG6O7wXvu7I=
=pUfi
-----END PGP SIGNATURE-----

Re: [PATCH] alternative to sys_indirect, part 1

[Michael Kerrisk]

On Thu, Apr 24, 2008 at 4:49 PM, Ulrich Drepper <drepper-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>
>  Michael Kerrisk wrote:
>  > * dup2() -- use fcntl(F_DUPFD) instead
>
>  Wrong.  You cannot implement dup2 with fcntl since the latter won't use
>  a file descriptor which is already in use.

True.  One could add a flag to fcntl() to provide that behavior.

>  > So the alternative to sys_indirect(), at least for the purpose of
>  > O_CLOEXEC and similar, would be to create 5 new system calls (or six,
>  > if one finds the signalfd() hack too ugly, which perhaps it is; or 7
>  > if one doesn't like Alan's suggestion for socket()
>
>  Without changing the socket interfaces (plural, socketpair) there would

Yes, I overlooked socket pair()...

>  have to be 7 new syscalls, with changing socket* to an IMO cleaner
>  interface 9.
>
>
>  Or we just add sys_indirect (which is also usable for other syscall
>  extensions, not just the CLOEXEC stuff) and let userlevel (i.e., me)
>  worry about adding new interfaces to libc.  As you can see, for the more
>  recent interfaces like signalfd I have already added an additional
>  parameter so the number of interface changes would be reduced.
>
>  Somebody please make a call and then let's go on with life.  I don't
>  care much either way anymore.  I do hope nobody thinks this is an issue
>  which can be completely ignored (see, e.g., the bug I pointed to the
>  other day).

Since I had to go search, here it is again
http://bugzilla.redhat.com/show_bug.cgi?id=443321
--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html