A couple of days ago I
was idly browsing slashdot in a quite moment. I was reading an article about
efforst of Novell to provide a stable kernel level API for device drivers.
The discussion quickly
devolved into the usual closed source vs open source drivers flamewar, but then
I stumbled upon the following 'pearl of wisdom'.
philosophical. Why does this problem exist? Has it ever occured to any of you
that device drivers are themselves a complete throwback and an obomination in
the 21st Century? We take them for granted, but there is no good reason
whatsoever for a computer peripheral to use "device drivers". None.
If you can't design a piece of
hardware that works through an existing standardised interface you're no kind
of engineer at all. And take your pick.. firewire, USB, RS232, SCSI…
Do you suppose every video display,
digital camera, audio converter and so on is somehow uniquely special, that it
is so ground breaking in its design that it needs custom crafted code just to
make it work?
We are so entrenched in our legacy
thinking that nobody, not even smart developers ever ask themselves the obvious
paradigm breaking question, why the hell should you need a device driver? The
reason is no more than a gross failure of modern computing, a failure of
standardisation, a failure of coordination and regulation. It is a failure of
ourselves as users and customers to demand a higher standard of compatibility.
It is a failure of us as developers and coders to solve a simple problem once
and move on.
Before you answer with some circular
reasoning that merely begs the question take five and think it through. I speak
as a software and hardware engineer who has designed and built entire computer
systems and written an operating system.
This idea is naive and
extremely shortsighted to say the least. The only way this would work is if
every conceivable device is accounted for in the hardware bus protocol
For some devices this is
already done. USB mass storage for example is a good example of OS transparent
device communications. As far as simple storage is concerned, no device drivers
But that is as far as it
goes. Consider the next piece of hardware a simple USB to serial port
converter. These devices are standard today, but the no-device-driver approach
would only work if this device was foreseen in the USB protocol specifications.
But even if it was, some
of these devices can double as a 8 bit digital IO port. This can be really
convenient. However, what would be needed to make them work? Either a device
driver or an extension to the USB protocol that would already be bloated.
And even if that could be
done, suppose my company wanted to add a feature, like runtime switching
between different serial modes (RS232 vs RS485). What would I have to do? Beg
the USB consortium to add that feature to the protocol spec? Bribe them? And
they would have to get a committee agreement by the time my company wants to
release the new product.
But even then, how would
the software know about the exact device capabilities? Remember, there would be
no device drivers. So the OS would have to provide numerous abstraction layers
to account for all options.
But hey, the OS vendor
has to put out new version for each new feature I want to add. So they had better
have a daily release cycle to put out new versions for all the new features
that all manufacturers think of. That would be so impossible it would not
happen at all. Or very slowly and limited at best.
Back to the glorious days
of DOS. Where all device support was done by the applications themselves. That
has to be an improvement over the abstract device interfaces that are only made
possible by device drivers.
You would think that a
system engineer with hardware and software experience would have a feeling for
these issues, or at least a sense of nuance before making statements like this.
Especially if he had written an entire operating system by himself, don't you