[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20091227085113.GX18217@ZenIV.linux.org.uk>
Date: Sun, 27 Dec 2009 08:51:13 +0000
From: Al Viro <viro@...IV.linux.org.uk>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
Cc: michael@...top.org, linux-kernel@...r.kernel.org,
netdev@...r.kernel.org, linux-security-module@...r.kernel.org,
andi@...stfloor.org, david@...g.hm, socketcan@...tkopp.net,
alan@...rguk.ukuu.org.uk, herbert@...dor.apana.org.au,
Valdis.Kletnieks@...edu, bdonlan@...il.com, zbr@...emap.net,
cscott@...ott.net, jmorris@...ei.org, ebiederm@...ssion.com,
bernie@...ewiz.org, mrs@...hic-beasts.com, randy.dunlap@...cle.com,
xiyou.wangcong@...il.com, sam@...ack.fr, casey@...aufler-ca.com,
serue@...ibm.com, pavel@....cz
Subject: Re: RFC: disablenetwork facility. (v4)
On Sun, Dec 27, 2009 at 05:36:48PM +0900, Tetsuo Handa wrote:
> Application writers know better what syscalls the application will call than
> application users.
Aren't you forgetting about libc? Seriously, any interface along the
lines of "pass a set of syscall numbers to kernel" is DOA:
* syscall numbers are architecture-dependent
* there are socketcall-style multiplexors (sys_ipc, anyone?)
* libc is free to substitute one for another
* libc is free to do so in arch-specific manner
* libc is free to do so in kernel-revision-specific manner
* libc is free to do so in libc-revision-specific manner
(... and does all of the above)
* new syscalls get added
* e.g. on sparc64 32bit task can issue 64bit syscalls
--
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