Slashdot Mirror
How About Drivers In Devices?
An anonymous reader asks: "I was setting up a new system the other day and after trying to find 30,000 different device drivers, it hit me: What's wrong with the idea of having basic drivers for common OSes in a flash ROM embedded within devices, so that when we plug the device in, the driver is then downloaded to the machine in question? You could always update it or override the process, but it would sure save us a lot of scrambling around for disks. Am I the only one who has thought of this?"
No.
TO BUY A NEW CAR WOULD MAKE YOU SEXUALLY ATTRACTIVE.
google fcode
I've had this sig for three days.
I've certainly thought of this at least once when trying to get something working that was being a pain in the ass.
Stop and think about what is actually going on here, though. The point of a driver is to provide glue between a standard set of apis and whatever the external device speaks. If you include the driver on the device, you just require a higher layer abstraction to manage the drivers - a driver driver, basically. What happens when there's a bug fix for the driver you install,and you upgrade/reinstall your system? Either the driver driver has to track dependencies and know when to override the card or you have to write the new drivers to EEPROM or some such. In the first case, you have to have an update list it can contact to find out if the card has the right version (your drive or WinXX died), and in the later, you drive cost up and potentially add new ways to fry hardware. And if you're doing a net enabled driver manager, why worry about what software lives on the card at all?
At best, you can support recent kernels of popular OSes. Older ones and newer ones will still have to ignore the supplied drivers and provide different ones. You're providing a shortcut for a possibly short temporal period at the cost of a new protocol, more on-board memory and engineering for the device, and a new driver manager. A better approach would be to ape a well standardized protocol for communication (like some really old modems and some very high end scanners and image setters do).
It isn't a great idea, cost-wise, and for non-throw-away hardware, there's no point. I have a NIC that I've had for 7 years currently happily doing service in a firewall. It is a piece of crap, but it works fine and outperforms my outgoing bandwidth. What good are Win3.1 drivers on that card going to do me, other than be potentially annoying and drive (ahem) the price up?
-j
I forget what 8 was for.
I have a digital camera and so does my friend. We were both pleasantly surprised to find that XP didn't require any drivers when we just plugged it into the USB port. The reason it doesn't need any drivers is because the protocol that our cameras use to talk down the cable is standardized (the Picture Transfer Protocol). No driver is needed, or more precisely, only one driver is needed, for every camera that implements the protocol.
Why is this possible? Because digital cameras are smart devices. They can be programmed to conform to a previously defined protocol. This is a good thing. My mouse is not a smart device. There is no microprocessor in my mouse, it is not programmable. It would be easy to come up with a protocol that all mice are expected to implement but it would not be used because that microcontroller in the mouse would cost twice as much as any of the other parts in the mouse. The solution is to make a bit of software that translates my mouse's particular hardware protocol into the defined protocol that my operation system understands. That's why we have software drivers.
Putting a rom in something as "unsmart" as a mouse would cost too much, and the first company that came out with mice that are half the cost but require you to install a driver would capture the market. This is what actually happened, way way way back in the days of the PC wars.
But thankfully, things are looking up. Devices are getting smarter. My optical mouse has a microcontroller in it and so does my digital camera. A whole lot of things that plug into my USB port have a microcontroller in them. Does this mean we should have software drivers in rom as you suggest? I say no! Because this would mean that we would still have all the "drivers only for windows" problems that we have today, and what about when you update your operating system, is the driver on the rom still going to work? No. The solution is to have all smart devices conform to a protocol that is standardized, like the picture transfer protocol for digital cameras.
How we know is more important than what we know.
First, cost: Compare the cost per MB of CD's with flash. To fit a driver in the flash you'd have to put a huge flash on the chip. And flash is EXPENSIVE! On the order of dollars per megabyte, where as CD's are a dime a dozen.
Second, you have to have a driver that knows how to fetch the driver from flash. So you need to establish a new interface on top of PCI to know how to get a driver, plus you have to have a universal OS ID that can be used to get the right driver, so that Win NT SP3 is unique as compared to Win NT SP4.
Third, you have to update the driver. I don't know about you, but i'm always nervous when I have to flash a component on my system.
Fourth, manufacturing. If you're going to build these things, the lead time on the flash image is probably longer than on a CD or a web-site. If the drivers are taking a while, you can send the board to the factory before the CD image.
Nubus was the proprietary bus interface used by Apple in the Mac II series. It was finally abandonned when Apple adopted PCI for internal extension. This approach was very good for plug and play, but very expensive.
I think that loading drivers inside peripheral is very reasonable: first it would be expensive and second how many drivers would there be? If you build a PCI card, this would mean you would need drivers for different plateforms (xx86, PowerPC ,Sparc and probably others) and different OSes. This means a lot of combinations. More reasonable ideas IMHO are:
You're only like the hojillionth person who has thought of this. It even got implemented on a fairly large scale by Sun. The SBUS cards from Sun used a general purpose driver written in "FCode" until the OS booted and the real driver could be loaded. One benefit of FCode is that the card can be used before the OS boots (useful for Ethernet and SCSI cards). The other great benefit is that FCode is CPU and architecture independent: it's an interpreted language!
I'll bet money that Sun wasn't the first company to implement the idea, and almost certainly not the first people to think of this idea. You're probably 30 years too late for that.
As many people have pointed out, this is sadly not possible for reasons of cost and maintainability. On the other hand drivers will always be around until all devices get smart and use only standard APIs. As a developer I can tell you that that is going to happen in the near future. In terms of the age of the universe, "not by the year 3000" is the near future.
An alternative solution would be a more controlled process for device identification. PCI goes a long way to do this, and most new devices have some sort of identification. Basically every model of every device from every manufacturer needs a unique ModelID which is easily retrievable according to the basic protocols of the bus in question.
The ModelID could easily be a 128 bit number (64 bits assigned to the manufacturer, 64 assigned by the manufacturer; they control that range).
Then we need some sort of industry level agreement (or non-profit organisation with lots of clout) to maintain a database of ModelID = Device name + driver (or at least where to find the driver).
We can dream ...
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Just search google for i2o split driver model. I'm not sure what ever happened to it, but the idea was to split the driver into two parts. One was a device specific OS independent driver which resided on the device (which had a processor on it), and the other part was an OS specific driver for a particular class of device, which would then work with all devices of this class. (One driver for all disk controllers, etc)
Besides, doesn't USB do something similar too? Quite a lot of devices work just fine with the standard driver for their device class. Think input devices, storage, etc.