5 ms·

I'm curious, how can someone implement device drivers (without knowing hardware details.) for a self-made OS like this?

raggi 5y ago
It seems to only target very commonly ported and generally understood hardware, and not many things. 32bit Intel, no arm. Bochs VBE and Intel graphics, e1000 and rtl8192 nics. They're very sensible targets as they'll let you run with event performance on most virtual machine platforms as they're commonly emulated and mature.
- jhgb 5y ago
  It would be cool to have something similar but specifically targeting Raspberry Pi these days. There you don't have a lot of variability either, and it might even turn out useful relative to its "bigger" (or "bloated"?) competitors.
  - raggi 5y ago
    Sadly Pi has some significant IP blocks that don't have open manuals or permissive drivers to work from, so targeting it for a home brewed OS is extremely hard work.
FranchuFranchu 5y ago
Usually hobby OS developers only write drivers for well documented hardware like the e2k
boricj 5y ago
Here's an example with the NE2000 network card (PCI only). I've tested it both on QEMU and with a real RTL8029AS card. Probably the most important thing is quality, RTL-level reference documentation. When you hit a dead-end, having a battle-tested Linux or BSD driver to peek at helps a lot, because hardware has quirks and the documentation might not tell the whole story. SerenityOS currently doesn't have a lot of tooling to help debugging drivers aside from kprintf() and kubsan. Other operating systems may offer more advanced capabilities, such as NetBSD's rump kernel where you can run drivers in userland for example. https://github.com/SerenityOS/serenity/pull/5191 https://github.com/SerenityOS/serenity/pull/5191
breckinloggins 5y ago
General tips: 1. Start with a QEMU emulated device. QEMU is more forgiving than real hardware and you can study, understand, and debug the "hardware impersonation side" of the QEMU code to see what happens when you set a bit in some register. 2. Pick a simple device. Don't start with the USB stack or Ethernet. Maybe try to reimplement the UART driver first. 3. Don't freak out about "device driver architecture" stuff like whether you need lock-free queues or allocation-free algorithms or ring buffers or... whatever. Just get it working. 4. Write a userspace program that uses the driver you'd like to see working. That'll motivate you to finish it. 5. Repeat. Until eventually you know how to write device drivers. :)
- toast0 5y ago
  > 2. Pick a simple device. Don't start with the USB stack or Ethernet. Maybe try to reimplement the UART driver first. A UART driver is great; then if you want to do Ethernet, virtio-net is a good start, and then carefully pick your physical ethernet card; something descriptor based will let you reuse the descriptor concepts you already learned. Realtek cards get a lot of shade, but aren't too bad to interface with and they're very popular; if you've got a bunch of computers, you've probably got at least a few realtek nics. Ethernet is cool, because then you can start communicating with the world (although there's a lot of stuff to get tcp going)

It seems to only target very commonly ported and generally understood hardware, and not many things. 32bit Intel, no arm. Bochs VBE and Intel graphics, e1000 and rtl8192 nics. They're very sensible targets as they'll let you run with event performance on most virtual machine platforms as they're commonly emulated and mature.

jhgb 5y ago
It would be cool to have something similar but specifically targeting Raspberry Pi these days. There you don't have a lot of variability either, and it might even turn out useful relative to its "bigger" (or "bloated"?) competitors.
- raggi 5y ago
  Sadly Pi has some significant IP blocks that don't have open manuals or permissive drivers to work from, so targeting it for a home brewed OS is extremely hard work.

FranchuFranchu 5y ago

Usually hobby OS developers only write drivers for well documented hardware like the e2k

boricj 5y ago

Here's an example with the NE2000 network card (PCI only). I've tested it both on QEMU and with a real RTL8029AS card. Probably the most important thing is quality, RTL-level reference documentation. When you hit a dead-end, having a battle-tested Linux or BSD driver to peek at helps a lot, because hardware has quirks and the documentation might not tell the whole story. SerenityOS currently doesn't have a lot of tooling to help debugging drivers aside from kprintf() and kubsan. Other operating systems may offer more advanced capabilities, such as NetBSD's rump kernel where you can run drivers in userland for example. https://github.com/SerenityOS/serenity/pull/5191 https://github.com/SerenityOS/serenity/pull/5191

breckinloggins 5y ago

General tips: 1. Start with a QEMU emulated device. QEMU is more forgiving than real hardware and you can study, understand, and debug the "hardware impersonation side" of the QEMU code to see what happens when you set a bit in some register. 2. Pick a simple device. Don't start with the USB stack or Ethernet. Maybe try to reimplement the UART driver first. 3. Don't freak out about "device driver architecture" stuff like whether you need lock-free queues or allocation-free algorithms or ring buffers or... whatever. Just get it working. 4. Write a userspace program that uses the driver you'd like to see working. That'll motivate you to finish it. 5. Repeat. Until eventually you know how to write device drivers. :)

toast0 5y ago
> 2. Pick a simple device. Don't start with the USB stack or Ethernet. Maybe try to reimplement the UART driver first. A UART driver is great; then if you want to do Ethernet, virtio-net is a good start, and then carefully pick your physical ethernet card; something descriptor based will let you reuse the descriptor concepts you already learned. Realtek cards get a lot of shade, but aren't too bad to interface with and they're very popular; if you've got a bunch of computers, you've probably got at least a few realtek nics. Ethernet is cool, because then you can start communicating with the world (although there's a lot of stuff to get tcp going)