Messages in this thread | | | Date | Mon, 28 Apr 2008 17:29:07 +0200 | From | "Michael Kerrisk" <> | Subject | Re: [PATCH] paccept, socket, socketpair w/flags |
| |
On Mon, Apr 28, 2008 at 5:13 PM, Ulrich Drepper <drepper@redhat.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
| |