Slashdot Mirror

← Back to Stories (view on slashdot.org)

How About Drivers In Devices?

Posted by Cliff on from the the-next-step dept.

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

5 of 103 comments (clear)

  1. Fat chance by codeButcher · · Score: 3, Interesting

    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.
  2. Re:Why not? I'll tell you why not.. by norwoodites · · Score: 3, Interesting

    Most of the recent video cards are flashable but the manufacture does not tell you this.
    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.

  3. Don't forget... by 3-State+Bit · · 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.

  4. Alternative: numbers & registries by Twylite · · 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 ...

    --
    i-name =twylite [http://public.xdi.org/=twylite], see idcommons.net
  5. JNDI by DeadSea · · Score: 3, Interesting
    I believe that this was part of the Java Naming and Directory Interface.

    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.