DragonFly kernel List (threaded) for 2006-02
Re: User-Space Device Drivers
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
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