OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 1:32 pm

All times are UTC - 6 hours




Post new topic Reply to topic  [ 7 posts ] 
Author Message
 Post subject: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 6:23 am 
Offline
User avatar

Joined: Thu Feb 26, 2015 5:07 pm
Posts: 4
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


Top
 Profile  
 
 Post subject: Re: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 9:39 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
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.

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 10:00 am 
Offline
Member
Member
User avatar

Joined: Wed Dec 01, 2010 3:41 am
Posts: 1761
Location: Hong Kong
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.


Top
 Profile  
 
 Post subject: Re: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 10:06 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
bluemoon wrote:
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?

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 10:12 am 
Offline
User avatar

Joined: Thu Feb 26, 2015 5:07 pm
Posts: 4
Combuster wrote:
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.

Quote:
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. :D

Cheers mate.


Top
 Profile  
 
 Post subject: Re: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 10:18 am 
Offline
User avatar

Joined: Thu Feb 26, 2015 5:07 pm
Posts: 4
bluemoon wrote:
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.


Top
 Profile  
 
 Post subject: Re: Sanity Check - Device Management
PostPosted: Wed Mar 04, 2015 10:20 am 
Offline
Member
Member
User avatar

Joined: Wed Dec 01, 2010 3:41 am
Posts: 1761
Location: Hong Kong
Combuster wrote:
bluemoon wrote:
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 7 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 18 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group