How About Drivers In Devices? 103
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?"
hmm, let me think (Score:4, Informative)
Re:hmm, let me think (Score:2)
Re:hmm, let me think (Score:5, Informative)
Re:hmm, let me think (Score:2)
IBM project (Score:2, Interesting)
Re:IBM project (Score:2, Funny)
Willy Wang: What meaning of this?
Lionel Twain: Is the. Is the. What IS THE meaning of this! Use your god-damned articles and prepositions!
(Sorry, no offense. Your post made me think of that great line from Murder By Death [imdb.com], and I just cracked myself up.)
Nope. not the first (Score:3, Informative)
All the Springboard expansion modules had drivers in the cards. Although, based on the more recent [handspring.com] 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.
Re:Nope. not the first (Score:1)
That's okay man! I'll always remember how those corporate FASCISTS stole your original idea!
Re:Nope. not the first (Score:1)
Re:Nope. not the first (Score:1)
Re:Nope. not the first (Score:2)
Look up... (Score:4, Informative)
How about devices that implement standards. (Score:1)
Just chose better devices and you're half way there
Modems that are just a serial port and not crappy WinModems.
USB storage devices that implement the USB storage protocall.
Printers that are PostScript - or at least PCL.
Video Cards that are VESA complient.
Sound cards that can pretend to be SB-16's
SCSI
Keyboards without those crappy 'internet keys'
Digital Cameras that implement the USB storage protocall
Re:How about devices that implement standards. (Score:1)
Then again, those cards couldnt do ONLY vesa, so you weren't throwing it away. Yeah, hell, implement the standardized way to do it, but if you have a better way, implement that, too, and require a driver for THAT. If joe schmoe loses his driver disk or wants to plug his camera into his homegirlz computer, he can do it, but it will do it in the standardized way.
Kinda like how I always need to turn to VESA when X doesnt support the video card I got duped into buying. At least i'm looking at X and not a blank screen right buddy?
Go away fool. (Score:2)
On a related note, I haven't seen a card in years that didn't have VESA compatibility. But VESA only provides an interface for the most basic featureset of a card. If you're using VESA compatibility mode instead of getting a proper driver, you're throwing away everything that sets a $250 GeForce4 Ti from a $20 S3 or Trident POS video card.
Same goes for SB16 compatibility - Lots of cards have this. Would I want to use it? No way, not with all of the benefits that newer cards offer.
Keyboards w/o "internet keys" - Hmm? I've never had any problems with such keyboards. Don't touch the "internet keys" and the rest of the keyboard is 100% identical to a normal PS/2 keyboard. In the case of "Internet Keys", usually they're just extra scancodes which the driver has no problem understanding and it's a simple matter of mapping the keys to a useful function in X or wherever.
Re:How about devices that implement standards. (Score:2)
Problem is cost for many people. Serial port modems generally cost at least twice as much as winmodems, SCSI drives nearly twice as much as IDE, Postscript printers can easily be more than twice as much as equivalent winprinters, and even PCL printers tend to run 1.5x the cost of a winprinter.
For an office situation, where budgets tend to be larger, and compatibility is more of an issue, your advice makes sense, but for most home users, it's just to expensive to do it the way you suggest.
Why not? I'll tell you why not.. (Score:2, Interesting)
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?!?!?!"
Re:Why not? I'll tell you why not.. (Score:3, Interesting)
This is so they can produce one card for both Mac/OpenFrameware and ia16 (correct because when an x86 boots up, the video bios needs to be 16bit) drivers and just change the driver before packaging.
In fact the cards on the Mac in include a real driver for PPC when say ati release a new version it is only a patched version. I do not think this is the case for Mac OS X though.
Re:Why not? I'll tell you why not.. (Score:1)
Anyone have a video card that is totally broken? Doesn't work any more? Try just reflashing it.
Put it in a machine, along with another card (so you can see what you are doing) and then download the bios from the manufactorers website, and download - hey presto a working card again.
Re:Why not? I'll tell you why not.. (Score:1, Funny)
you, sir, are not geeky enough to be reading slashdot.
Re:Why not? I'll tell you why not.. (Score:1)
At some point we had to return/replace more than 50 creative sb awe 64 because the firmware got "corrupted" sometimes. 3 years later we found a software to rewrite the flash on these cards. Why do you need to put R/W memory in a device and leave it R/W so any random event (read windows "detect hardware" thing) will kill your device ?
Re:Why not? I'll tell you why not.. (Score:1)
Actually, there was an article a while ago on slashdot about a technology that embedded a flash card onto a cd to make it 'piracy' proof.
Just to further drive you up the wall
Re:Why not? I'll tell you why not.. (Score:1)
BTW, what on earth is a FlashROM? Flashable memory that can only be read, never written???
Re:Why not? I'll tell you why not.. (Score:1)
Give or take. You can't call FlashROM (well, EEPROM to be specific) RAM because the writing cycle isn't Random Access. The write cycle has to be done sequentially, or sometimes in blocks, so it can't (easily) be used like normal RAM for the writing bit.
HTH!
Waw - cool ideea - NOT (Score:1)
Re:Waw - cool ideea - NOT (Score:1)
Why has this never been done? It's just code the OS has to load. As long as every OS for the said platform follows the standard then you're good to go. Actually I've always wondered why nobody has written code to allow Linux to load Windows' drivers? Most things work now so it's not a big issue now, but back in the day this would have help Linux to use anything Windows can.
Re:Waw - cool ideea - NOT (Score:1)
I use "can't" loosely. Anything's possible, but that doesn't mean anything's practical.
I think everyone's thought this, but... (Score:5, Insightful)
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
Fat chance (Score:3, Interesting)
Re:Fat chance (Score:1)
Mr. Gates: Yes, we'll allow you to use the name "windows" to state that you include the windows drivers directly on the disk, assuming, of course, that your product "adds value" to match our standards. It's important to our customers that, for stability and compatibility sake, that there not be any possibility that the wrong OS driver be used, so the only driver on your rom must be the windows XP2003 incarnation. You can offer drivers for other operating systems, but only by postal mail, prepaid by the customer.
We were just having this discussion today! (Score:5, Insightful)
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.
Re:We were just having this discussion today! (Score:1, Informative)
Re:We were just having this discussion today! (Score:2)
And here's the problem with your "standardized protocol" solution-- Although mice conform to a standardized protocol, different mice have different feature sets. Even though the standard driver will work, you generally want to install mouse-specific drivers to enable extra buttons and configure things. Thus, standard protocols don't do away with the need for device-specific drivers.
Re:We were just having this discussion today! (Score:1, Funny)
<mouse-event>
<type>
move
</type>
<xdelta unit='twip'>
300
</xdelta>
<ydelta unit='twip'>
300
</ydelta>
<wheeldelta unit='clicks'>
0
</wheeldelta>
<button index='1'>
0
</button>
<button index='2'>
0
</button>
<button index='3'>
0
</button>
<x-retinalscanner>
12381737378931731987397821312
</x-retinalscanner>
</mouse-event>
Hmmm...of course we may need to use firewire or USB2 for our mice...
Or a more concise encoding (Score:1)
Hmmm...of course we may need to use firewire or USB2 for our mice
XML isn't always the best language framework, especially for streaming events over a low bandwidth link. When I begin to run into more markup than data, I typically switch to a simple text-based encoding, and if that isn't efficient enough, I use binary.
A single packet ("move x+10 y-7 b1+") shouldn't take too much bandwidth over USB 1.
Too expensive/too little benefit (Score:4, Informative)
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.
Re:Too expensive/too little benefit (Score:2)
How many drivers need to be 650MB in size?
If you need only a few 100KB, then the cost for flash is significantly reduced. In addition, with CDs, you need to order a significant number. Any rev to the driver requires a whole new CD run.
Of course, the rest of your analysis is pretty good.
CD-R for short runs (Score:1)
In addition, with CDs, you need to order a significant number.
Not anymore [cdrfaq.org].
Re:Too expensive/too little benefit (Score:1)
There's no reason you'd have to do this. First, the OS always should use drivers installed on the system itself; never directly from the device's flash. Plus, the "driver driver" should copy the drivers from the flash to the PC only when the OS doesn't have any other drivers to use. Therefore, you can use new drivers easily without ever updating the flash.
I could see this being uesful for NICs. If the OS doesn't come with a driver for your NIC, then how do you get the driver? You can't download it off the 'net, so you need a floppy or a CD, which isn't always convenient.
Been done (Score:4, Informative)
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:
NuBus not Apple-proprietary (Score:1)
> Apple in the Mac II series.
Just a quibble. NuBus was not an Apple-proprietary technology. It was designed by MIT and first used by Texas Instruments. Apple licensed it for use in the Mac II and its followons.
Re:NuBus not Apple-proprietary (Score:2)
Re:NuBus not Apple-proprietary (Score:2)
Re:Been done -- by Amigas of course (Score:1)
Machine Code? (Score:2, Interesting)
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):)
Open Firmware (Score:2, Informative)
Re:Open Firmware (Score:1)
Don't forget... (Score:3, Interesting)
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.
Only Person? Not likely! (Score:5, Informative)
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.
Re:Only Person? Not likely! (Score:4, Informative)
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 [sun.com] and A Sun Example [sun.com]
Here's Open Firmware info from apple [apple.com] and Mac Example. [rutemoeller.com]
Alternative: numbers & registries (Score:4, Interesting)
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 ...
Re:Alternative: numbers & registries (Score:1)
http://pciids.sourceforge.net
To include the driver needed?
Interesting - could be done almost automatically (If someone could write a script which took a card description, googled for it, found the latest drivers for all OS's, and included a link to it.)
Re:Alternative: numbers & registries (Score:1)
And don't you think 64bits for vendor and device is a bit much? That would allow for 18446744073709551616 vendors with an allotment of the same number of devices for each one.
64 bits.... (Score:1)
24 bits for a vendor, allowing 16777216 vendors.
16 bits for the device, allowing each vendor to produce 65536 types of device. If this runs out, they can apply for a new vender number.
24 bits for a serial number, allowing for 16777216 devices of each type (with a new device number if they produce more than this many of any specific part)
Or alternatively - 24 bits for device type, 24 bits for vendor ID number, 16 bits for device version.
Maybe these numbers should be fooled with a little, since the link indicates that 16 bits for a vendor is perfectly adequate. It might be possible to increase the size of the device ID number to more than 32 bits by adding version and revision numbers.
Of course, the vendor ID could just be an 8 char non-terminated string. Most of the companies could have their name squished into 8 chars without getting too confusing.
Re:64 bits.... (Score:3, Insightful)
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.
Re: 64 bits.... (Score:1)
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.
makes it sound more like you were unaware of these capabilities with PCI and were proposing a peripheral bus that had these capabilities.
A "whole lot" of new manufacturers? Doing a quick grep of this [ieee.org] reveals there to be ~6243 different vendor prefixes. A mere 0.0003721117 of the vendor prefix address space of ~16mil is being used. Now perhaps 16mil devices per vendor is a bit low in this day and age of pervasive networking, but they seemed to alleviate this problem quite well by allocating multiple prefixes to a vendor. If you would like to provide information to backup your claim of MAC addressing problems I would honestly be very interested in seeing it.
Comparing this to IP addressing is like comparing apples to oranges. Yes theoretically speaking there could be infinite companies producing infinite different hardware products. But in the real world it takes capital to start a company, and even more to bring a product to market. It doesn't seem to take so much of that hard earned cash to plug in another host to the internet though, now does it?
While I do agree with you about the size of the IP address space and the y2k problem being quite shortsighted, I really do not think this is relevent in this case? Yes IPv6 has a 128bit address, but that's because in the wonderful future eveything imaginable will have an IP address.
The only thing I was calling into question was you pulling the figure of 128bits out of thin air. Now this discsussion has just become totally irrelevent to the original question.
Simpler solution... (Score:2)
...would be to store just a URL on the device where drivers can be downloaded from. This way the host OS could go out and pull the drivers automatically. There would need to be some sort of naming convention to differentiate between drivers for the various versions of Windows, Mac OS, Linux, etc.... but this would avoid having to store all flavours of drivers on the device itself.
Of course if the device IS your method of connecting to the net then this may prove to be quite hard! ;-)
Re:Simpler solution... (Score:1)
URLs are not guaranteed to be stable (Score:1)
store just a URL on the device where drivers can be downloaded from.
URLs are not guaranteed to be stable, even when the company follows the W3C's rules [w3.org]. Even Tim BL admits that "Pretty much the only good reason for a document to disappear from the Web is that the company which owned the domain name went out of business or can no longer afford to keep the server running" or had the domain forcibly taken from them in UDRP arbitration. Personal computer peripheral manufacturers do go out of business.
This already exists - I2O (Score:4, Informative)
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.
Re:This already exists - I2O (Score:2)
FireWire is similar, in that it's very no-driver. Storage devices, cameras, and so on (ideally) Just Work, using standard interfaces and suchforth. Never used one though, so I can't tell you what the practical implementation is like.
--Dan
JNDI (Score:3, Interesting)
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.
Re:JNDI (Score:2)
Re:JNDI (Score:2)
Sounds like Microcode (Score:2)
On a mainframe, every device has intelligence(usually). They all have a channel processor and everything. The channel processor is the one who reads and processes the microcode. All of the processing needed for that device to works usually occurs on that device. All the mainframe wants to do is pump data out through it. Basically, it's already happening if at a lower level. Take Graphics cards. The GPU handles alot of the rendering independant of the processor. It just happens to share a bus with the main CPU. This may not be having drivers built into the device, but there is talk of bringing channel like functions to PC's especially for I/O intensive devices like Hard Disks, Graphics Cards and Network Cards. When this happens, all the kernel would have to know is how to talk to a chanel type device. At that point, it would just pump data. What kind it is would in not matter much to the main CPU. At least that's the way I understand it.
Re:Acorn RISC OS "Podules" (Score:3, Informative)
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)?
--JoeRe:Acorn RISC OS "Podules" (Score:1)
>machine with one installed.) How about PR #1 (to
>print) or PR #6 (to reboot)?
Real men use C300G
[ot] apple ][ remiscence (Score:1)
Oh, how many times have I rebooted with FAA6G.... Or hooked CIN/COUT... I actually wrote a 'macro package' that hooked CIN and expanded certain control keys out to strings for you. It was one of the first programs I wrote after getting a proper assembler. Prior to that, I hand coded opcodes directly in the monitor. 2C 30 C0.... 4C 00 03.... ah the memories... (Ok, sometimes, if I was programming under DOS 3.3, I'd load Integer BASIC into the language card and do F666G. But it was a PITA.)
But now I'm extremely off topic...
--JoeTo take FCode a step farther... (Score:2)
I'd like to see printers and the like use Java-based drivers that implement a standard interface. You could either load the java into your print spooler from the printer, or have the printer provide an RMI-accessible object that your spooler can talk to. Woohoo! Finally, OS and printer independence!!!
Re:Use a VM! (Score:1)
It's called Open Firmware [google.com], and the 'VM' is a Forth interpreter/compiler.
--JoeMy take on the situation (Score:1)
You'd need the following functions:
enum_driver_arch()
get_driver_offset(this_arch)
get_driver_size()
retrieve_driver(offset, size)
as well as:
store_driver(driver, arch)
The problem is you'd end up adding a few $ to each device by adding flash, even NAND flash. With the scale of production, I don't think it'd work out economically. It'll come down to a guy in the store seeing two modems, one is $3 more, and says that there will ne no driver hassle, and the one next to it says "plug-n-play"
Which one are you going to choose? The cheaper one!
Lack of Standards (Score:2, Insightful)
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.
Big Printers already do this (Score:2)
The Apple II had this (Score:2)
That said, the trend these days is towards less and less intelligence in the peripheral and more and more dependence on the OS and main CPU. The Winmodem is an extreme example. So while you've got a good idea, it's so 1970's and not nearly trendy enough for today's manufacturers :-).
No, you're not the first (Score:2)
The driver wouldn't be for common OS, but rather would confrom to UDI.
Universal Driver Interface.
On startup the OS would extract the driver from ROM, check that it has no updated version installed, and load the driver from ROM/HD (if there is updated version).
In a sentence... (Score:2, Insightful)
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.
a better idea, standard interfaces (Score:1)
Like postscript for printers?
just build every soundcard with a standard interface, you could still have all the fancy features but the driver would just be the standard sound interface.
regulate the standards via some group so that new modules or interface types could be added and and updated. like USB3 comes out, the group introduces the OPEN standard and then microsoft, linux, freebsd, etc etc could take that OPEN interface and built a driver for their OS. every device sound card whether it were a realtek onboard chip or a sound blaster audigy would interface to the OS the same way. You would need drivers for extended features not supplied by the standard interface, but id rather see my sound card work properly in the first place than b*tch about my EAX not functioning.
I'd like compare it loosely to IDE drives. Their are many different IDE drives as well as different chips on the drives and different firmware etc etc, but you can still plug in ANY ATA100 drive into an ATA100 controller and it would flawlessly, no driver installs, a stable flexible interface(that is now outdated by SATA
be this is just my opinion
PostScript is expensive (Score:2)
why not just make standard interfaces for all or most all devices? Like postscript for printers?
Because PostScript printers cost twice as much, part for the added hardware for running the PS interpreter, and part for the interpreter software license (if you choose Adobe's over Aladdin's).
I'd go for a simpler interface where the host sends the printer a PNG of the page, and the printer prints it. The host should also be able to query the printer's paper sizes, hardware pixel densities, color model (black, cmyk, or hexachrome), and dot spread. Then Any Old Rasterizer(tm) would work.
One Driver for All OS's (Score:1)
One driver, no fuss, no muss.
The "content industry's" take on standard drivers (Score:1)
But then a bunch of folks got together to define a common standard for firewire chips that came to be called OHCI. There are several OHCI firewire chips, and they can all use the same driver on any given OS because they are register-compatible.
Microsoft Windows only supports OHCI. It doesn't support PCILynx.
Funny thing is, the "content industry" - movie, tv, RIAA, etc., participated in setting the standard for OHCI. Firewire is a big deal in professional video production; Apple got an Emmy for developing FireWire.
It seems the content industry was concerned that allowing for promiscuous mode in OHCI would help defeat copy protection of content that's delivered on the firewire bus.
So there's no promiscuous mode provided for in the OHCI standard.
PCILynx cards are I think no longer manufactured because Microsoft won't support them and OHCI cards are so ubiquitous. The Mac OS still supports them but Apple builds all their new Macs with OHCI.
It's getting hard to find PCILynx cards. I've been fortunate to get ahold of a couple CardBus PCILynx cards inexpensively. The one source of PCI PCILynx cards I've found charges $290 for them. So instead of getting a PCI card for my Mac 8500 I got a PCMCIA to PCI adapter that claims to support the Mac and I've been all day trying to get it to work.
That's what setting standards for this sort of thing will get you. The DMCA hardwired into the protocol. That's not what you want.
Search for "copy protection" at the 1394 Trade Association's website [1394ta.org].
Personally, my plan is to start writing a GPL protocol sniffer soon. I'm going to make it cross-platform, using a library to abstract the system-call interface. Mac OS 9 and Linux support should be easy; OS X support will hopefully be straightforward. To support Windows I'll have to write a PCILynx driver for it.
AmigaDOS did this (Score:2)
It is worth noting that the operating system for the Amiga was mostly in ROM as well, but the shell and all the commands were on hard disk or floppy or whatever. If you had enough ram you could mirror ROM into ram and boot from it, or load a disk file and boot that or whatever. Otherwise, the OS ran (more slowly) out of ROM but didn't take up space. Ah, the joys of a big address space.
As has been noted elsewhere, OpenFirmware machines (including every sparc-based sun) have a forth interpreter and you write some hacked up forth for drivers which the OS uses. Of course, it's ungodly slow, so it doesn't replace actual drivers in the OS, it just lets you get started. You get enough intelligence to, say, netboot, or load a kernel, and you get to use your primary graphics display. This is the reason why a Sun's console is slower than X, even on the 68k suns and the earliest sparcs, with their crappy CG3 framebuffers.
You are definetly not the first! (Score:2)
We have semi-standard VESA mode for graphics cards. If we only could get good 2D & 3D minimal standards.
But what I am trying to say: If we could agree on some minimal standards to talk to all kinds of things, but to make to most of them, you would need specalized driver. Graphics, Video, Sound, Storage, Input, all these would benefit from these "minimal standard drivers". Just plug in a sound card, and you get sound. Maybe not highes quality or Dolby Stereo, but usable for your games.
Well you get my drift.
NCR's SCSI CAM implementation (Score:2)
Designing the interface to the driver in the BIOS was a bit of a challenge, because it had to work with everything from the 5380 (a very low level SCSI chip--basically all it implemented was those parts of SCSI that were too fast to do in software efficiently, like REQ/ACK handshakes during data transfer) all the way to the 537xx, which was basically a SCSI coprocessor, capable of doing everything, including management of a queue of requests.
To use the BIOS driver, you had to load it into memory, and relocate it (a relocation table was included in the BIOS), and give it a table of callback functions that it could use to do things like enable/disable interrupts, allocate and free memory, map virtual to physical addresses, and stuff like that. So, for each supported OS, we had to write a driver that could do that. This part tended to be fairly simple.
This worked very well. You could take a Unix system with a 5380, and decide you needed better performance. Shutdown. Replace 5380 card with 53720 card. Reboot. You now have better SCSI performance.
A way I found helpful to think about this while desiging it was to think about this question: "If you could design the ultimate intelligent SCSI card, what would you want it to do? How would you interface between it and the OS?". We basically then designed for that interface, and that's what the driver in the BIOS implemented. The NCR cards were essentially intelligent SCSI cards that just happened to not have a CPU onboard...so they had to make use of the system CPU.
Instead of drivers (Score:2)
You just notify what "class" of device, and the OS magically knows what to do.