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?"
A friend of mine at IBM is doing a project just that. He is part of team that write Perl to download driver for IBM server.
Let's imagine that a virus somehow got on a ROM chip for a popular video card. The company would have to issue a recall. The investors would be angry from losing money over it.
I'm suprised that virus writers haven't figured out how to update the firmware of DVD drives with infected drivers to ensure a longer life for their creations.
In review, storing drivers in ROM chips bring extra cost from R&D and Flashable ROM chips introduce new places for evil viruses to hide. Extra costs will be passed on to us and I don't want to pay $425 for the next top of the line video card just because it includes a fancy new ROM chip when Windows VGA driver is good enough.
"Oh no, a few minutes of 640x480! How will I ever survive?!?!?!"
If they don't even bother to include drivers on disks "for the most common OSes", how are you going to get them to include those drivers on flash?
Free, as in your money being freed from the confines of your account.
Doesn't the device require machine code to run? I mean, seriously. How is the downloadable device driver (lets say the device is USB) going to work on different processors and different operating systems? This just won't work. The thing that _has_ to be done is for standards to be used. You know... standards.. things you could find in the pre-monopoly era.
It would be easy for devices to have in its ROM the windows device driver. But what good is that really? Just pick a standard for a certain device to communicate and leave it at that... If you do something different, publish it on the web somewhere so different OS vendors can read your document and build a device driver around it. Hell, freaking distribute sample C code or something of an implementation of the device driver so people can port it easier.
Some graphics card vendors obfusicate their driver to hide the implementation of their device, which I do not compleatly understand I guess. If they really wanted they could pick a type of bytecode and publish that. It isn't difficult to get some java byte code and translate it to whatever the native processor is. I'm not talking about a full fledged java implementation to do this, just translating the op codes since as far as byte codes go. Java has the best published ones for a virtual machine out there. They could reinvent the wheel if they pleased, I don't care.
But either way, ya... some of this stuff sucks. Just refuse to buy things that don't have decent standards, as a previous poster was speaking of. I would of never bought my Sony Clie had I realized the USB/memory stick storage was not a published standard. As far as the Clie is concerened neither linux or freebsd have working drivers to mount the memory sticks on them. (Sony laptops that have the memory stick reader in them can usually be mounted in freebsd/linux as SCSI devices). I love or hate Sony depending on what side of the bed I wake up on. (The side with my TV and PS2 is the good side):)
Device drivers take up memory to load. So, include enough RAM for the driver on the device itself, so that each device adds its weight to the bus.
</ironic>
You're advocating something very similar....think about it.
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
If I recall correctly, this protocol would handle both discovery and drivers. The basic idea is that each type of device would have some industry agreed upon interface. For example a printer would support and interface with a "public static Status print(Document d) throws IOException" interface. There is a way to ask for devices near you that support such an interface. The devices that do, would respond with an Object (or driver) that implements that interface and you would be good to go.
Microsoft didn't support it so hardware vendors don't support it, so it is fairly dead at this point. However, it would have been kewl.