Messages in this thread | | | Date | Sun, 26 Feb 2012 07:26:10 -0500 | Subject | Re: Can we move device drivers into user-space? | From | Richard Yao <> |
| |
On Sun, Feb 26, 2012 at 5:47 AM, Henrik Rydberg <rydberg@euromail.se> wrote: >> > 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.
I do not see what prevents an in-kernel context switch into a ring 3 context with a different process address space. Is it necessary to remove the code from the kernel tree before someone can do this?
| |