lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sun, 26 Feb 2012 11:47:01 +0100 From: "Henrik Rydberg" <rydberg@...omail.se> To: Bobby Powers <bobbypowers@...il.com> Cc: Ted Ts'o <tytso@....edu>, Greg KH <gregkh@...uxfoundation.org>, Guenter Roeck <guenter.roeck@...csson.com>, Jidong Xiao <jidong.xiao@...il.com>, Kernel development list <linux-kernel@...r.kernel.org> Subject: Re: Can we move device drivers into user-space? > > The main issue that set me off has been sufficiently diluted in the > > (selective) discussion so as to no longer make sense as a reply: At > > some point, in-tree or out-of-tree will no longer be distinguishable, > > Please explain how you would be unable to distinguish between a driver > that lives in the kernel source tree, and one that does not. The SUD pointed to in the beginning of the thread is an example of this, but I was not thinking of it in quite so literal terms. Rather, I was imagining that as the kernel grows and the in-kernel interfaces matures, the amount of actual communication between different portions of the code diminishes. Code on opposite sides of a stable interface is, for all practical purposes, separated. Whether that code lives in-tree or out-of tree is then of little consequence. To try to prevent another flame war, let's make it clear that I am not saying that the most powerful in-kernel argument, that code can be changed, is unimportant. Maybe code, like so many other things, arranges itself in a scale-free critical fashion, which would forever warrant a monolithic approach. Maybe it would even make sense to have userspace join the same tree as well. There is however a frofoundly political aspect here, which cannot be expressed in terms of code. Also, in practise, breaking things down into manageable chunks is usually a good idea in the end. Thanks, Henrik -- 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