OSDev.org

Micro-Kernel Server/Services/Driver/Module Load Synchronization
This is actually a stumbling stone for people when writing a Micro-Kernel, or any type of kernel in actuality. I think a lot of troubles come when people actually realize that things have to be loaded or have synchronized loading. For example: The disk driver can not completely load before the virtual file system (module/driver/service/server) loads. In practical thinking you actually have to ask your-self who tells the disk driver to load and what controller does it drive?

I am sure a lot of people actually get to a point where they can load some type of module or meta-module of code, into memory or execute in memory in a specified manner. The general assumption and outcome is to just load all modules one after another as quick as possible. I am not saying this is a bad idea but simply giving a example of a situation you might find your self in.

When thinking about it I come up with three broad types of load synchronization:

1. Just load them.
Let each driver implement it's own waiting mechanism. Such as allowing the VFS to define messages that can be used to communicate if it has finished loading and such... basically the developer implementing custom load synchronization.

Just for a more in depth example we could imagine a bunch of people being lead into a room, and then saying o-kay now get something done. The main point here is that each people will have to wait for the other appropriate person to become ready. The communication by mouth should be the equivalent of sending messages back and forth between modules.

2. Tree loading approach. The kernel module loads a <nameless> module which then attempts to load a:

Well the idea is simply to eliminate the Physical Disk Manager (JUST FOR EXAMPLE!) to load before the Virtual File System Module. Instead allow the VFS module to explicitly load the Physical Disk Manager instead and so forth essentially using the structure of the tree as guide for synchronization.

3. Layer Loading Approach
Here each driver or module is assigned a layer number 0 to <whatever>. The lowest module are loaded first, and send a message back saying they have loaded then the next layer (1..2...3...) and so forth is loaded while this same process repeats.

Hi,

My boot loader/s load a boot image into memory, which contains many files. Modules that are needed during boot are found within the boot image and started in order (e.g. boot loader starts the boot manager; boot manager starts the user interface code, then the CPU detection module, then the memory module, then the kernel setup code; the kernel setup code starts the kernel modules).

After this the VFS module is found and started by the kernel setup code, and everything in the boot image is transfered to the VFS (which caches these files, and acts like a RAM drive until device drivers, etc are started). Once the VFS is ready the device manager is started by the kernel setup code. The device manager does some initialization and tries to find and start a motherboard driver, and if a motherboard driver is found it waits for it to complete it's initialization.

Everything up to this point is started in a sequential order. Everything after this point isn't.

Now the device manager scans for devices and starts devices drivers as it finds devices. Each device driver is responsible for starting anything it needs.

For example, the device manager might find a network card while scanning the PCI bus and start a network card driver, and the network card driver will iniitialize and then might load a TCP/IP stack. The TCP/IP stack might initialize and start a HTTP and FTP server.

If the device manager finds a video card it'd start a video card driver, and the video card driver might start some user interface code, and the user interface code might display a login screen.

If the device manager starts a hard disk controller driver, then the hard disk controller driver will find any hard drives connected to it and start some file system drivers.

All of this happens in parallel - for e.g. at a specific point in time there may be several device drivers and several other processes all independantly being started and initializing.

Each module is responsible for telling whoever started it it's state - if it needs to wait for something else, if it can't start or if it's become operational. If a module starts one or more other modules, then that module's state is same as the state of the least ready module it started. For example, a network card driver might start the TCP/IP stack, but the TCP/IP stack might need to wait until a certain file can be accessed, so the TCP/IP stack will tell the network driver it needs to wait and the network driver will then tell the device manager it needs to wait. When/if the file becomes accessible the TCP/IP stack will continue and become operational, then tell the network driver it's become operational and the network driver will tell the device manager it's become operational.

The device manager monitors the modules (device drivers) it started, and waits for all of them to become operational. If all device drivers have become operational or if nothing has changed for 15 seconds, the device manager informs everything else that the OS itself has become operational and the next stage begins. When this happens any modules that are still waiting for resources send an error message to the system log (to tell the user or system adminstrators what went wrong) and terminate.

Some modules become operational and then wait for the device manager to say that the entire OS has become operational. For example, user interface code displays a login screen and allows a user to type in their user name and password, but won't allow the login to continue until the OS has become operational - it might display a "waiting for the rest of the OS" message if the user has tried to login before the rest of the OS is ready. Even though users can start typing in their user name and password before the system becomes operational, I'd expect the rest of the system to become operational before the user/s finish typing.

Also, once the system becomes operational the VFS code will start trying to flush caches files (originally from the boot image) to file system/s (e.g. creating the files if they don't exist in the file system, and removing them from RAM if they already exist in the file system). This forms part of the OS installation - when installing the OS you'd just create an empty file system and let the VFS write the files to the file system. This means you'd boot from an installation CD, create the empty file system, then start using the OS like normal (and won't need to reboot during OS installation at all).

Once a user does login the user interface code starts GUIs and/or CLIs and/or full screen applications (what the user interface code starts is determined by that user's configuration or the system's default configuration). From here the user can logout or start applications, etc.

In general (except for the early boot code), everything is started/initialized in parallel and there are no dependancy problems - each module can only depend on the module that started it and the file system/s (the VFS supports "notifications" for this, where a process can ask for a message to be sent when something changes). The idea is to avoid slow boot-up times caused by a fully sequential startup (like traditional Linux) while also avoiding the dependancies mess that most parallel startups cause (like more recent attempts to improve Linux boot times).

Lastly, I'll have something that keeps track of which files were used during boot, so that it's easy to (automatically) put these files into a boot image so that modules that need the files don't need to wait until file systems are started. This also forms part of OS installation (the OS installer can automatically create a new "machine specific" boot image to install and use for subsequent boots), and it'd be possible to have some sort of service that automatically keeps the boot image up-to-date.

Of course I haven't implemented most of this yet, and I'm sure I'll have teething problems in some areas....


Cheers,

Brendan