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?"
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, please realise that I did note in my original post that PCI already has ID numbers of this sort; but that all new devices on new busses need it AND it needs to be more controlled / standardised. i.e. A PCI card manufacturer can use the same ID for all revisions of their card if they want, even when some use different drivers. Its stupid, but they do it.
Second, no, 64 bits isn't overkill. There've been problems in MAC addressing for some time becuase 48 bits was supposed to be enough. Now you're throwing in a whole lot of new manufacturers, a whole lot of new devices, and hopefully mandating better control over the numbering by saying that every revision (hardware/firmware combo) must have a unique number.
While large swarthes of the ID space may be unused, don't underestimate the importance of having enough to LET it be unused. Let's not go into the shortsightedness of having 32 bits for IP addressing, 2 digits for a year, etc.
64 bits would probably be fine if you exclude a serial number; but even then 128 bits would be compatible with current software standards (GUID/UUID), which would be convenient.
i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
Drivers in microcode or ,machinecode would be quite small, especially if gzipped. Make the microcode a standard instead of just assembly machine code, and it will work easily for any windows linux solaris macosx computer.
Toughest part is making a standard. Once a standard companies will theoretically flock to do this..
Secondly I think it should allow for just putting in a URL that the OS could use to download the driver. This will be used by cheaper parts like special headphones or mice.
Thirdly for older products.. there should be ONE standard online database of the product numbers and serial numbers where companies would submit their drivers, and OSes would download them as needed. Strong crypto will be needed for this.
Overall this shows the severe lack of standards dominant in this industry.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Standards, not drivers.
Take digital cameras as an example. Yah, it's sure be neato to have to driver on the camera to avoid having to find it! Or, like mine (and alot of cameras nowadays) the camera can just adhere to a standard (ie USB Mass Storage Device) and Just Work(TM). Which is better?
Sure, this doesn't work for some things, but it applies to most external-type things that putting a flash driver into makes sense anyway.