[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4810BAE3.5070406@redhat.com>
Date: Thu, 24 Apr 2008 09:52:51 -0700
From: Ulrich Drepper <drepper@...hat.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>
CC: Michael Kerrisk <mtk.manpages@...il.com>,
David Miller <davem@...emloft.net>, alan@...rguk.ukuu.org.uk,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
akpm@...ux-foundation.org
Subject: Re: [PATCH] alternative to sys_indirect, part 1
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Linus Torvalds wrote:
> So while I don't dislike the indirect system call, I do think that if we
> can handle a large case of the problems with an added flag to already
> existing system calls,
The easy, clean cases I already handled back when. I wouldn't have
implemented socket this way to preserve the function signature but
that's just me. It's hopefully over now.
What remains isn't that easy to fix. We need syscall interface changes.
Yes, I'd like to avoid them, too. But sometimes the existing
interfaces are just wrong and now we have to make a decision: new
syscalls or sys_indirect. No way around it.
As far as the userlevel interface is concerned, this is not quite the
same. As explained before, I've anticipated some of the problems.
signalfd, eventfd have no flags parameter in the syscall but I have them
in the userlevel interface. I.e., any kernel change will be hidden. At
least as far as the interface signature is concerned.
So, the question still is on the table: do you want sys_indirect?
If yes, then then new sys_accept would use sys_indirect instead of a new
entry point. If you don't want sys_indirect, then I'll submit a new
sys_accept syscall (already have the patch here ready to go).
- --
➧ Ulrich Drepper ➧ Red Hat, Inc. ➧ 444 Castro St ➧ Mountain View, CA ❖
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFIELrj2ijCOnn/RHQRAtewAJ4+826rxwtckEvvOaXdiNSr/5ECPACfWwTn
hgt5EYrrj/imBloPE7DxHJA=
=T6LW
-----END PGP SIGNATURE-----
--
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