OSDev.org

After some research I designed the following scheme to represent the devices in my kernel:

PS: I'm targeting an ARM SoC (Raspberry Pi), but I believe these ideas can be applied to PC.

The hardware enumeration will build a tree. In the root level we have the "System" node, which represents the computer. It children are buses (e.g. USB, I2C, SPI, etc.) and each bus have it attached devices (mostly peripherals). In my case, I have the 'virtual' SOC bus which contains devices implemented directly in the SOC and can't be enumerated (e.g. graphic display). Finally, we have 'virtual devices' which are devices built on top of other devices (e.g. filesystems, host bridges, etc). They could be used, for example, to mount a NFS filesystem (filesystem device attached to a network device).

Devices and buses are associated to a driver and contains a block of information (e.g. vendor, model, addresses, class, etc.).

Something to illustrate:

• System
  • SOC bus
    • Display device
  • USB bus
    • Host Bridge (e.g. USB hub)
      • Printer
      • Camera
      • Host Bridge (e.g. another USB hub)
        • Printer
    • Mass storage (e.g. USB stick, external HDD)
      • Ext2 filesystem
    • Keyboard
    • Mouse
    • Display
    • WiFi dongle
  • SPI bus
    • Some device

I admit that It's a not detailed description, but it gives a general view of the design.

Question: this seems a good way to represent a device hierarchy?

I think that's how Linux does it. At least, that's how lshw shows it. Personally I can't see anything wrong with it - with a design like that it's pretty easy to define an interface for the drivers at each level (e.g. a "bus driver" interface (implementing read/write/status calls for addressed devices on the bus - you'll need some way to refer to a particular device), a "storage device driver" interface (implementing block read/write calls), etc.) and then "snap together" the drivers required for the devices connected and the buses that they're connected to.

onlyonemac wrote:I think that's how Linux does it. At least, that's how lshw shows it.

When reading about Linux I came to the same conclusion

onlyonemac wrote:Personally I can't see anything wrong with it - with a design like that it's pretty easy to define an interface for the drivers at each level (e.g. a "bus driver" interface (implementing read/write/status calls for addressed devices on the bus - you'll need some way to refer to a particular device), a "storage device driver" interface (implementing block read/write calls), etc.) and then "snap together" the drivers required for the devices connected and the buses that they're connected to.

I wanted to achieve just that. I'm starting to implement an ext2 filesystem code and I wanted to be able to read partitions from various sources (e.g. USB mass storage, SD card, network, etc).