lkml.org 
[lkml]   [2012]   [Feb]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Can we move device drivers into user-space?
On Sun, 26 Feb 2012, Henrik Rydberg 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.

the point that you seem to be missing is that the interfaces between the
different areas of the kernel are not stable, they change over time. When
both sides of the interface are in the kernel, this is not a problem, both
sides get changed, but if one side was out of the kernel, then you either
can't make the change, or have a flag day change where both sides need to
change in lock-step (and downgrading is hard as both sides need to change
again)
This is completely ignoring the performance and security aspects of
userspace components vs kernel components.

Ted is explaining the performance aspects well, but let's look at the
security aspects as well.

It's not just a case of "if something in userspace crashes, it doesn't
crash the kerenl", it's also a case that "if you have a userspace
component, then the kernel must sanity check the userspace interface to
defend against rogue userspace". Doing these checks is not cheap (adding
to performance overhead), and may not even be possible (how do you know
if the command being sent to the SCSI bus is safe or not?)

David Lang


\
 
 \ /
  Last update: 2012-02-27 00:11    [from the cache]
©2003-2011 Jasper Spaans