Re: Can we move device drivers into user-space?

[Henrik Rydberg]

> > How long can one grow and still claim to _be_ a kernel?
> 
> You tell me.  I know of lots of "kernels" that are far bigger than
> Linux, and people still consider them a kernel.

I would love to be enligthened.

> > The current
> > (arbitrary) split between kernel and userland was made a long time
> > ago. For a number of reasons, of course, but not least out of
> > convenience. Projecting the current kernel growth ten years into the
> > future, will there still not be another (arbitrary) convenient split?
> 
> Why?  What problems are we having with our existing user/kernel split
> that would drive such a change?

Maintenance. Sure, as soon as an area grows too large for a single
person, the current structure will ensure it divides so that the patch
stream becomes manageable. We have already seen ample examples of
that. But the overall structure of the kernel will become less and
less manageable, and the likelihood of duplicates and maintenance
problems will increase. At some point, intra-system interfaces will be
introduced, such that several areas may coexist and expand
individually. At that point, the convenience split will already have
been made, and the subsystems may well reside in different places.


> > Even so, the main point was not whether a secondary split may or may
> > not happen, but what will happen to the quality of the total system
> > when/if that happens. I doubt the fate of userland drivers would be so
> > heatedly discussed if everyone believed that work would be carried out
> > with the same quality currently found in the kernel.
> 
> Quality is not the only reason we don't want userspace drivers for some
> types of devices.  Realize what drivers provide to userspace today and
> you will understand that.

I think I do understand how software interfaces and streamlining
works, so I fail to get the point here.

Thanks,
Henrik
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/