Analysis of an opinion piece

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'.

Let's get 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 specifications.

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 are needed.

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 think?

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>