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

Comments

hmm, let me think

[vsync64]

No.

Re:hmm, let me think

[dimator]

This one?

Nope. not the first

[Monokeros]

I thought of this a few years ago. Then Handspring went and did it. Which is something everyone thought was very cool when they first came out.

All the Springboard expansion modules had drivers in the cards. Although, based on the more recent PDA offerings from Handspring, it looks like they're abandoning the technology. The Treo doesn't have a Springboard slot and the Visor Edge requires an extra caddy thing to plug the modules into (May or may not come with it. idunno).

However, including the drivers was made possible by the fact that there was only one platform to bundle drivers for, the platform is pretty static. There aren't that many PalmOS updates and they don't change that much between versions.

Look up...

[addaon]

google fcode

Too expensive/too little benefit

[mrolig]

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.

Been done

[Matthias Wiesmann]

If I remember well (somebody correct me), Macintosh Nubus cards had something like this. The card's ROM memory contained information about the card and then a low level driver. This meant that you could plug in a video card and it worked without having to resort a common denominator (say VGA). At that time, most PCs had trouble figuring out on what DMA the soundblaster was sitting on.

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:

• Have busses where you can query the device for its type and id and also the assumed bus speed. And have devices tell their type. Serial ports are nightmarish in this respect. The trick to figure out the speed is a hack (this is the reason for the AT sequence, the modem could recognised the AT pattern at any rate and thus guess the rate). Also the system cannot figure out what is connected to a serial port in a reliable fashion.
• Generic drivers. Many new USB components (small disks, mices, keyboards) do not need any drivers because they export a standardized interface.
• Flexible drivers. This is an intersting feature of the driver system of Darwin / OS X, IO/kit. Drivers are object oriented. A PCI SCSI card drivers is basically two objects: one that inherits from a PCI class, and another that inherits from a SCSI controler class. This does not remove the need for drivers but should help make them simpler: a driver would only contain code that handles stuff that is specific to the component.

Only Person? Not likely!

[nathanh]

Am I the only one who has thought of this?

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!

http://sunsolve.sun.com/data/802/802-3239/html/sbu sandfc.html

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.

Re:Only Person? Not likely!

[Polo]

Actually, what's funny is that this works on Everyhing BUT PC's. It works on Suns and on Macs.

On sun it's called openboot and it's called open firmware on the mac.

You can access it with STOP-A on a Sun, and for a Mac it's Command-Option-O-F on boot.

Here's info from sun and A Sun Example

Here's Open Firmware info from apple and Mac Example.

This already exists - I2O

[earthman]

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.

Open Firmware

[Anonymous Coward]

Open Firmware has already solved this. The device driver is written in Forth. A Forth interpreter in ROM compiles it for the local machine.

Re:We were just having this discussion today!

[Anonymous Coward]

No, a mouse *does* contain a microprocessor (a microcontroller to be precise). For example, Logitech mice contain a Zilog MCU and it is smart - it can understand both serial and PS/2 protocols.

Re:Acorn RISC OS "Podules"

[Mr Z]

Apple ]['s also stored the device firmware on the card for their add-in cards. You had 2K-bytes of ROM allocated to each card at $Cx00, where 'x' was the slot number. For cards that needed more storage, you could use the 8K of space from $C800 - $CFFF, but I forget the exact rules for sharing that space.

PR #3 anyone? (Enables 80-column mode on a machine with one installed.) How about PR #1 (to print) or PR #6 (to reboot)?

--Joe