Sanity Check - Device Management

[Malleus]

Hi all,

I've lurked this forum for quite a while, but never posted because I've not been able to find the time to start an OS project before. However, I'm making good progress on one at the minute and just wanted to see if you thought my approach to device management makes any sense.

The project is a 32-bit OS for ARM-based single board computers (like the Pi, essentially). It's monolithic and has to be recompiled for each device that I want to run it on. But, obviously, I want to define some reasonable hardware abstraction so that only the really low-level code files need to be changed when porting.

(It's being written in C (not C++) so I'm making heavy use of pointers.)

I'm not really sure how other projects handle device management (USB, on-board controllers, and integrated peripherals). But what I'd planned to do is this:

• On startup, a "device manager" builds a linked list of structs for devices that it knows about. Initially, these will be low-level drivers for integrated peripherals. E.g. an SPI driver, GPIO, USB controller etc.
• It then adds a slightly-less-low-level "device" for each integrated periph. E.g. on the Pi, there'd be a "SD card" device. Each of these devices points to functions in the previous level of devices. So the SD card code would use functions from the SPI driver. But could, in theory, be pointed at a USB device instead (for USB card readers).
• Some devices might have a third level. For example, the SD card driver might detect partitions on the card and add another set of devices for specific file systems. These drivers use functions in the SD card driver, which in turn uses the SPI drivers.

In theory, only the lowest-level code will need to be changed between platforms. The kernel doesn't allow any user-mode processes to talk to a device directly, and I figured this structure would allow the kernel an easy way to deal with complicated devices. For example, a process loader might look for a FAT16/FAT32 device and read a file. But a routine to partition/format the SD card could go direct to the "SD card" and ignore file system details. Other code might access the SPI device directly and not care what kind of device is attached to the other end of the SPI wires.

Does this sound like a reasonable approach, or have I missed something fairly important? It seems to me to be the kind of thing that other OSes might do. But there's going to be a lot of work to do to get all the devices working, so I've held of starting this until I can be at least somewhat confident that it'll actually work.

All the best,
M

[Combuster]

An SD card is not necessarily MBR partitioned (it could be GUID), and a partition isn't necessarily FAT (it could be ntfs or ext2/3/4 or something worse). In the case of a Pi, the devices on the USB port are unpredictable as well, so you will want to have a separate mechanism that takes a device X and checks if an instance of device Y can be a child of that.

I'm missing references to that part of the plot.

[bluemoon]

Also note there there may not be exactly 3 level of "devices". For example, you may have PCI bus -> USB -> USB hub -> USB -> keyboard -> USB -> sdcard.

I took a recursive approach. I do a "root probe" which hard-coded to do pci bus probe for now, and get a list of child, and pull in the related drivers. Then probe the child, and get a list of grand-child, etc. This build a device tree.

This also solve the "hardcode FAT" issue since the disk driver is responsible for probe the FS type and pull in correct FS-driver.

[Combuster]

disk driver is responsible for probe the FS type

Did I just read that you were duplicating the FS checking code into every block storage driver?

[Malleus]

An SD card is not necessarily MBR partitioned (it could be GUID), and a partition isn't necessarily FAT (it could be ntfs or ext2/3/4 or something worse).

Yup. This is why I wanted to separate file system drivers from SD card access etc. Ultimately, I will have to support a few other file systems but since the Raspberries (which are one of the devices I'm testing on) can have a FAT16 or FAT32 boot partition, I know I can't avoid supporting those.

In the case of a Pi, the devices on the USB port are unpredictable as well, so you will want to have a separate mechanism that takes a device X and checks if an instance of device Y can be a child of that.
I'm missing references to that part of the plot.

I'm a little light on specifics concerning USB devices at the moment, granted. Although there'd have to be a USB controller driver at the lowest level to abstract the Pi's access to the USB ports from those on other systems. It's also the area where I'd have to accommodate for device removal. Not looking forward to writing USB support.

Cheers mate.

[Malleus]

Also note there there may not be exactly 3 level of "devices". For example, you may have PCI bus -> USB -> USB hub -> USB -> keyboard -> USB -> sdcard.
I took a recursive approach. I do a "root probe" which hard-coded to do pci bus probe for now, and get a list of child, and pull in the related drivers. Then probe the child, and get a list of grand-child, etc. This build a device tree.

You're quite right - 3 levels is neither the minimum nor maximum. There could be a lot of variation here.

Thanks for your comment - it got me thinking. I might implement this as a proper tree instead, as you've described. Seems to make more sense.

[bluemoon]

disk driver is responsible for probe the FS type

Did I just read that you were duplicating the FS checking code into every block storage driver?

Well my actual implementation there is one more layer for disk's block device on top of the physical media device. Anyway I just want to point out the tree-building concept instead of naive 3-level, so was not going to complicate it with too much details.