netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* [PATCH 00/18] flag parameters
@ 2008-05-06 21:18 Ulrich Drepper
  0 siblings, 0 replies; 2+ messages in thread
From: Ulrich Drepper @ 2008-05-06 21:18 UTC (permalink / raw)
  To: linux-kernel, netdev; +Cc: akpm, davidel, mtk.manpages, torvalds

This is an update for the previous series which should address the
comments Andrew had.  The controversial function Davide wrote is gone.
There is no flag conversion anymore.  We still introduce new names for
the constants but the values are the same as the O_* constants.

This leads to some strange-looking code where we in one moment check
for, say, SOCK_CLOEXEC, and in the next for O_CLOEXEC.  But I added
in a separate, new patch code which checks for the consistency of the
constants.

I modified the headers in <linux/*> to define the new values by
include <linux/fcntl.h> and then simply define the new constants
based on the O_* constants.  That's the safest a nd least troublesome
way.  Otherwise we would have to create arch-specific headers.  None
of the modified headers should be used by userlevel code.  Therefore
the namespace pollution is no issue.

For those who just turn in, these patches add flags to various functions
so that new file descriptors can be created with atomically setting the
close-on-exec flag.  This is critical, in multi-threaded apps we otherwise
can have file descriptor leakage or worse.  Since it is so either and
often needed, I also added code to create new file descriptors with
O_NONBLOCK set.

In future there will be other uses.  Like a O_* flag to enable the use
of non-sequential descriptors.

Some interfaces are not exported at userlevel with enough flexibility
to allow extending them.  For those we need new userlevel interface.
This is the case for:

 - paccept
 - epoll_create2
 - dup3
 - pipe2
 - inotify_init1

We do /not/ need new interfaces for

 - signalfd4
 - eventfd2
 - timerfd_create
 - socket
 - socketpair

These either have flags parameters in the interface exported by glibc
or (in case of the socket functions) overload a parameter with a bitset.

Each semantic change has a test program.  For archs other than x86 and
x86-64 you'll have to add the appropriate syscall number.

The patches all apply individually in sequence and the source tree
remains compilable and runnable.

^ permalink raw reply	[flat|nested] 2+ messages in thread
* [PATCH 00/18] flag parameters
@ 2008-05-05  3:42 Ulrich Drepper
  0 siblings, 0 replies; 2+ messages in thread
From: Ulrich Drepper @ 2008-05-05  3:42 UTC (permalink / raw)
  To: linux-kernel, netdev; +Cc: akpm, davidel, mtk.manpages, torvalds

This series replaces the individual patches I sent out before.  They
introduce changes for all the file descriptor-generating syscalls which
do not have a flags parameter (or where it is not handled).

I think I addressed all the comments people made on the previous patches.
New in this series is support for pipe and inotify_init.  These are
straight-forward extensions like the rest.  Both require new userlevel
interfaces, though.  We need new userlevel interfaces for:

 - paccept
 - epoll_create2
 - dup3
 - pipe2
 - inotify_init1

We do /not/ need new interfaces for

 - signalfd4
 - eventfd2
 - timerfd_create
 - socket
 - socketpair

These either have flags parameters in the interface exported by glibc
or (in case of the socket functions) overload a parameter with a bitset.

In addition to support for setting the close-on-exec flag I also added
support to set the non-blocking mode.  This is how most modern, scalable
code should work and adding the support comes almost for free.  Support
to enable non-blocking is not added for dup3 (for obvious reasons)
and epoll_create2.  For the latter I have not found any support in the
kernel.  In case I missed something let me know and  I'll add the few
lines of code.

Each semantic change has a test program.  For archs other than x86 and
x86-64 you'll have to add the appropriate syscall number.

The patches all apply individually in sequence and the source tree
remains compilable and runnable.

Regarding the little mapping tables for the flags.  There are multiple
copies with the same values (for now).  We could play tricks for mergable
ELF sections to avoid this minimal duplication.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2008-05-06 21:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-06 21:18 [PATCH 00/18] flag parameters Ulrich Drepper
  -- strict thread matches above, loose matches on Subject: below --
2008-05-05  3:42 Ulrich Drepper

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).