User-Space Device Drivers

William Grim wgrim at siue.edu
Tue Feb 28 18:27:55 PST 2006


Emiel and Matt,

I understand what each of you are saying.  I understand that this work 
may or may not be used in the end, but it's a good thesis project and 
one I will complete to the best of my ability.  It may also prove to 
perform better than some people think it will, causing some to 
reconsider approaching driver development in user-space; on the other 
hand, it may prove that this approach still isn't useful for certain 
things such as drivers that need direct access to hardware.

My goal is to supplement what DFly currently has available in terms of 
kernel-space drivers.  My reasons aren't exactly for the reasons either 
of you have, but it's just so that adoption goes smoother.  For example, 
it's not like drivers could all be placed into user-space over night; 
that would be a radical change that wouldn't allow thorough analysis as 
to whether moving the driver from kernel-space to user-space was even 
beneficial.

Ultimately, I think that from an engineering perspective, a hybrid 
kernel probably is the preferred treatment of most kernels over pure 
microkernel and pure monolithic approaches.  However, think of the 
possibilities with a user-space framework... it could make it so easy to 
setup virtual devices (devices on other systems that appear to be on 
your own system) transparently when it's obvious that the CPU is not the 
bottleneck (the I/O link itself would be).

Matt, I may have some questions for you regarding DFly soon.  If I can't 
find the answers in the source or docs, perhaps I could hit the news 
list with them and get some feedback from you?

Thanks much, friends!
-- William Grim




More information about the Kernel mailing list