Resources about Resource Management in OS

[sebihepp]

Hello community,

after about 8 years I am back in hobby OS developing. I wonder if there is any valuable resource (wiki, books, websites) about resource management in OS, specifically about everything else than memory. (Devices, etc.)

I know about memory management, IPC and Threading and how to implement them. I also know about PCI, MemoryMappedIO, Ports, etc., but I am lacking a good understanding of how to handle them, specifically of devices. A device can be accessed via Ports and PCI and MMIO, for example. How does the OS know what Resources belong to one device without knowing anything about the device itself? When and how to handle exclusive access? How to know which driver to load?

I looked in the wiki, but it has in the overview page only topics about memory management.

Best regards
Sebi

[Octocontrabass]

A device can be accessed via Ports and PCI and MMIO, for example. How does the OS know what Resources belong to one device without knowing anything about the device itself?

ACPI and PCI tell you which resources belong to which device.

When and how to handle exclusive access?

Drivers should have exclusive access of their device's I/O unless they specifically request otherwise. For example, the PCI bus driver must have exclusive access to the legacy PCI configuration access mechanism, since two drivers trying to access it at the same time can conflict, but it can delegate read-only access to the PCIe extended configuration space since there's no risk of conflict that way.

How to know which driver to load?

ACPI and PCI tell you enough information about each device to load an appropriate driver.

[sebihepp]

Thank you.

I didn't dive into ACPI before and it's helpful if there is all the info there and in PCI.

I assume some drivers interfaces must be specified by the kernel itself. For example for Filesystems, because the kernel needs to load files. (for the drivers)
And something like APIC, interrupts and PCI is integrated into the kernel itself, because it is a resource that is managed.
Will USB Keyboards, etc. also appear on either ACPI or PCI?

One more question: Lets say I detect a FAT32 filesystem and I have 2 or 3 drivers for FAT32. (Assume one delivered with the OS and the other on was written by the user itself)
How to know which driver of them to load? I thought about first time asking the user and then storing the information on HDD. One OS application could allow to switch the drivers for devices.


Just getting a picture in my head...

Best regards
Sebi

[Octocontrabass]

I assume some drivers interfaces must be specified by the kernel itself. For example for Filesystems, because the kernel needs to load files. (for the drivers)

Usually, the VFS is the reason why the kernel specifies the filesystem interface. Loading driver files can be handled by a userspace program. Of course, since your kernel is responsible for arbitrating communication with drivers, you're free to enforce whatever interfaces you like.

And something like APIC, interrupts and PCI is integrated into the kernel itself, because it is a resource that is managed.

APIC and PCI don't have to be integrated into the kernel. It's a good idea to integrate both, since the kernel has to use both drivers in order to manage the hardware, but it's possible for them to be separate.

Will USB Keyboards, etc. also appear on either ACPI or PCI?

USB keyboards will be attached to a USB controller on the PCI bus. Your USB keyboard driver will use an interface provided by your USB controller driver, and your USB controller driver will use an interface provided by your PCI driver. (There may also be one or more USB hubs between the USB controller and the USB keyboard.)

One more question: Lets say I detect a FAT32 filesystem and I have 2 or 3 drivers for FAT32. (Assume one delivered with the OS and the other on was written by the user itself)
How to know which driver of them to load?

That's up to you!

[nullplan]

One more question: Lets say I detect a FAT32 filesystem and I have 2 or 3 drivers for FAT32. (Assume one delivered with the OS and the other on was written by the user itself)
How to know which driver of them to load?

Microkernels always have this hen-and-egg problem of needing the FS driver to load drivers, so there is no way to load the FS driver. Most Microkernels solve that by loading an initial RAM disk/tarball or what have you, and loading its contents as drivers so they are available. The InitRD is loaded by the bootloader to get around the above problem.

Once that is done, you just differentiate between different drivers with different names. That's why you can mount a FAT32 partition as "vfat" or "msdos" in Linux. User picks which one they want in the mount command line/system call.

[rdos]

One more question: Lets say I detect a FAT32 filesystem and I have 2 or 3 drivers for FAT32. (Assume one delivered with the OS and the other on was written by the user itself)
How to know which driver of them to load?

Microkernels always have this hen-and-egg problem of needing the FS driver to load drivers, so there is no way to load the FS driver. Most Microkernels solve that by loading an initial RAM disk/tarball or what have you, and loading its contents as drivers so they are available. The InitRD is loaded by the bootloader to get around the above problem.

I use a different approach. The FS driver is (almost) an ordinary application, but it is not a file on the disc, rather is bundled with other drivers in the OS binary, and then can be loaded from the binary before the filesystems are available, even before the RAM drive. I manage this by with some "fixes" in the PE loader that reads from the OS binary instead of from a file. The OS binary is created with a tool based on a configuration file, and so the user can decide which drivers to load by adding them to the file. There is no way to load drivers from discs, and so malious code cannot load new drivers or autostart new programs.

Once that is done, you just differentiate between different drivers with different names. That's why you can mount a FAT32 partition as "vfat" or "msdos" in Linux. User picks which one they want in the mount command line/system call.

I find the idea that you must mount filesystem unwanted.

[rdos]

Will USB Keyboards, etc. also appear on either ACPI or PCI?

No, USB devices can be identified by their function or vendor & product through device desciptors. Therefore, these devices are more like in their own category. There are also classes of devices within the USB specification, and USB keyboards are a special case of a HID device. The HID specification is very complex, but can handle many different types of input/output devices.

The USB devices then can operate on a multitude of different USB hardware controllers, including UHCI, OHCI, EHCI and XHCI. They can also operate on multiple levels of USB hubs. USB controllers are PCI devices (although they don't need to be, actually). They only implement the USB specification, not specific functions like an USB keyboard.

[nullplan]

I use a different approach. The FS driver is (almost) an ordinary application, but it is not a file on the disc, rather is bundled with other drivers in the OS binary, and then can be loaded from the binary before the filesystems are available, even before the RAM drive. I manage this by with some "fixes" in the PE loader that reads from the OS binary instead of from a file.

So basically the same as the InitRD approach, but the InitRD is baked into the kernel binary. Thus following the idea of "configuration by compilation". Which can work, but Linux in particular is demonstrating that most people just want a single kernel binary, and to create the InitRD separately. Most people don't want to rebuild the kernel (or even have the kernel sources around) just because something about their boot config changed.

I find the idea that you must mount filesystem unwanted.

And I find automounting and drive letters unwanted. We'll just have to agree to disagree on this. If I connect a dying drive to an OS, I would prefer if the OS did absolutely nothing to that drive unless I explicitly ask it to, because any access may be the last one. And an OS that autodetects and automounts the file systems on the disc will really not help here.

[rdos]

I use a different approach. The FS driver is (almost) an ordinary application, but it is not a file on the disc, rather is bundled with other drivers in the OS binary, and then can be loaded from the binary before the filesystems are available, even before the RAM drive. I manage this by with some "fixes" in the PE loader that reads from the OS binary instead of from a file.

So basically the same as the InitRD approach, but the InitRD is baked into the kernel binary. Thus following the idea of "configuration by compilation". Which can work, but Linux in particular is demonstrating that most people just want a single kernel binary, and to create the InitRD separately. Most people don't want to rebuild the kernel (or even have the kernel sources around) just because something about their boot config changed.

My tool doesn't do compilation and it doesn't require sources. It uses already compiled and linked device driver files (and in the case of the FS, FS server app executables). So, basically, instead of having those files in the usual FS and loading them through script files, my approach embeds all drivers in a single OS binary, and then the driver files don't need to be in the FS of the target system.

Actually, things like APIC and PCI are driver files, and those never could be in the FS since the FS needs them to operate. The actual kernel only consists of very basic functions like descriptor management, paging, and physical & kernel memory management. Even the scheduler is a driver file.

[sebihepp]

It is all getting clearer now. So most things in modern pcs can be accessed via ACPI and PCI, right?
Of course PCI (With its Bridges, etc.) leads to USB Host Controller, leads to USB Hub, etc. But initially nearly everything is done via ACPI and PCI.

I also found the article about the HAL very helpful. The HAL consists only of interface definitions that drivers must then implement, correct?

And I need to think further about how drivers are represented in my OS.
Monolithic or microkernel? (In kernel space or not)
Are they own processes or only a collection of functions?
I like the idea of classes in C++ very much. Every driver defines classes which inherit the according HAL interface. And then the driver creates one function which returns a pointer to the class. (Works because of the vtable)

I see, I need much more time to get the clearer picture...

[rdos]

I wouldn't say that ACPI is very helpful. About the only thing that it is good for is to determine IRQs for devices that need IRQs and that cannot handle MSI or MSI-X, which today is mostly older devices. It can also be used to discover "legacy" devices that are not PCI based, which is even older devices.

I only use ACPI with modern hardware (APIC-based), and not with older, and only to map IRQs. I can list the ACPI name space, but I don't use it for anything.

As for USB hubs, those are not discovered with PCI. They are discovered through their USB descriptors, just like other USB devices.

Actually, it is possible to detect IRQs with probing for most devices, and so those configurations would not require ACPI either.

[nullplan]

I wouldn't say that ACPI is very helpful.

I believe we had this conversation already, but

• Reboot
• Shutdown
• Power management: querying batteries, setting power states, etc.
• Querying platform input devices, e.g. power button or reset button
• Querying platform temperature sensors before a core meltdown occurs
• CPU discovery
• and yes, IRQ routing

All sound fairly important to me. Admittedly you can do some of these without ACPI, but it becomes more reliable with ACPI. Also admittedly, ACPI can contain a fair bit of nonsense. The appendices of the XHCI spec contain ACPI code to specify the layout and connections of USB connectors, and I don't see myself ever using that. But just because there's data I don't want to use in there, doesn't mean the whole thing is useless.

[rdos]

Reboot

Generating a tripple fault has better reliabilty than the ACPI method.

Shutdown
Power management: querying batteries, setting power states, etc.

I'd avoid using shutdown and power management. It's too error-prone and not useful enough for a hobby OS project.

Querying platform input devices, e.g. power button or reset button

You can easily live without that functionality.

Querying platform temperature sensors before a core meltdown occurs

A realistic implementation of this doesn't use ACPI, rather the CPU vendor interface, simply because most motherboards don't have the right ACPI objects. The same goes for changing operating frequency, voltage and throttling. All of this would be useful, but it is missing or incorrect too often. Actually, the BIOS manufacturer doesn't know exactly which CPUs that are used, and so exports the wrong ACPI objects. Because major OSes (Windows & Linux) uses vendor supplied CPU support code and not the ACPI stuff, nobody tests this properly anymore and so it is often non-functional.

CPU discovery

These are in tables and so don't require an ACPI parser.

Perhaps the major reason why to NOT use ACPI is that major OSes (again Windows & Linux) have their own parsers that are extremely tolerant for errors in ACPI. The public ACPICA module doesn't have enough tolerance against this and so could "die" when the parser in Windows won't die, and so you might end up with a system that works on Windows but not your OS. And, of course, the BIOS manufacturer think everything is ok if Windows works, and doesn't care if Windows internally finds a lot of errors in the ACPI scripts.

Also note that for ACPI to work at all, you must provide it with the Windows version that it was designed to operate with, otherwise it might give you the wrong ACPI code in order to stop users from using non-supported operating systems. It might even reboot on it's own after x minutes if you don't give it a "proper" version. Even Linux will pretend to be a recent Windows version.

[Korona]

Linux uses ACPICA. ACPICA is developed directly by Intel, so it is quite robust. Yes, you have to claim that you are Windows. That is even part of the ACPI specificiation by now; the specification requires you to claim that you are Windows even if you are not.

You cannot use the I/O APIC on real hardware without an AML parser, and on some mainboards you cannot use all devices without also using the I/O APIC. For example, I have a mainboard where the Intel HDA controller's IRQ is only routed to the I/O APIC (not the legacy PIC or MSIs) and the routing is only enabled after you run the _PIC method. Without ACPI, you simply cannot use the sound hardware on that machine. That's another good reason to support ACPI.

[rdos]

Linux uses ACPICA. ACPICA is developed directly by Intel, so it is quite robust. Yes, you have to claim that you are Windows. That is even part of the ACPI specificiation by now; the specification requires you to claim that you are Windows even if you are not.

I don't think that Linux use the official ACPICA anymore. They have forked the code since quite some time ago. That's why Linux can run on motherboards that have a broken ACPI implementation that won't run on the official ACPICA. You can even create logs with errors in ACPI on Linux.