4 ms·

I think the answer is to have device drivers implemented as part of device firmware.

• yjftsjthsd-h 6y ago
  Oh, like UEFI or openfirmware drivers? That's... a pretty neat idea, actually. That would lower the barrier to entry, certainly. About the only issue I see is then trusting those drivers (I don't really trust hardware mfgs, and you'd have to update them somehow), but that seems doable.
• giantrobot 6y ago
  That becomes extremely problematic as a lot of devices anymore ship with bare minimum firmware to turn themselves on and require the host to upload firmware to actually work. The "drivers" on disk are then the modules required by the OS and a big blob of firmware. Other times devices are just a thin PHY interface and all of the work is done in software inside the driver. There's nothing on the device to even run onboard firmware. So many devices can't store their own drivers for the host to use, let alone store drivers for multiple operating systems.
  • Koshkin 6y ago
    So the idea is similar to the one at the base of (the original) OpenGL, i.e. that of a hardware API that can be used by any OS.
    • giantrobot 6y ago
      There's a bit of that already with USB device classes. A keyboard might have a bunch of special features if it at least works with the USB HID keyboard class it will have base level keyboard functionality. For some things like HIDs this can be pretty workable. For more complicated peripherals it is far more challenging if not impractical. That's not to say device drivers should be an insane Wild West of compatibility shims and edge cases but some blanket solution doesn't solve all problems.