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
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sun, 26 Feb 2012 11:47:01 +0100
From:	"Henrik Rydberg" <>
To:	Bobby Powers <>
Cc:	Ted Ts'o <>, Greg KH <>,
	Guenter Roeck <>,
	Jidong Xiao <>,
	Kernel development list <>
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.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

Powered by blists - more mailing lists