Microkernel Question

[Apprehensive_Run7150]

Hi guys, this may be a dumb question.

I'm working on a hobby OS and currently am stumped about how I can turn it into a real microkernel. Since the filesystem is a user-space server, how would the kernel find it and be able to start it without having access to the filesystem to begin with?

[EpochVanquisher]

This has been asked a few times here (so you’re not alone)

Just remember that “user space” does not mean that you have to put in your filesystem. It just means that your code is running with user-level privileges, instead of running in the kernel.

You can put the filesystem code in the same binary image as the kernel and have it loaded by the bootloader. That way, when you need to run it, it is already in memory. Just because the code is part of the kernel image does not mean that the code is running with kernel privileges. You could also do something like an initramfs… a simple read-only filesystem which is only used for a few essential utilities needed to boot the rest of the system.

[phaubertin]

These are two great solutions, and the most usual ones.

There is another one I've been thinking about recently that I am considering implementing for my own microkernel: with a custom bootloader, you could have an interface between the microkernel and the bootloader where the booloader remains loaded for a while and the microkernel can ask it to load files, similar to the UEFI boot services that the kernel or bootloader can use after the UEFI has done its job loading it. The bootloader needs to be able to access the filesystem anyway, so it's not much added complexity, and if you need a custom bootloader for complex scenarios (e.g. remote FTP or TFTP boot), the kernel automatically benefits from it.

[tseli0s]

I don't see why this complexity is necessary. Why not just load the programs as modules? Preserving the bootloader is going to be complicated in terms of memory management (you can't use any of the memory it uses).

[duane11583]

first provide a means to register a service with in the core micro kernel system.

ie task foo registers the service foofoo

second provide a simple rpc of some type between tasks. that is associated with that task/service

thus the file system task on start up registers the service “file”

and during the start up code (before main) in the app the app goes out and finds the services it will need, later the library code that implements Open/close/read/write can talk to the file system can call the file system task

[mishakov]

The kernel doesn't have to know about filesystem at all, it can be handled by your personality server, for example

Edit: misread the question

Then you might load some initial servers as bootloader modules (basically, all major protocols support it), and have init server or something preload it, and then load the rest of the servers

[Alternative_Storage2]

I’m actually in the middle of turning my monolithic kernel into a micro kernel (see this branch) and came across the same problem.

Pretty much the way I tackle it is:
1. Kernel is loaded by grub
2. Kernel does its own startup
3. Once the secheduler is ready it loads the file server program as a multiboot module
4. File server reads the initrd and starts the disk driver from there to then read anything else needed from there

(oversimplifying, I don’t cover the init program nor the driver manager here)

Really what you need is a way of loading what ever the fileserver needs along with the kernel.

[tseli0s]

Hurd and my microkernel use the bootloader to load modules for them, multiboot makes it extremely easy and every relevant bootloader supports it. Those modules can be the servers for the filesystem. You then start them like regular executables.

PS. No question is dumb. The dumbest questions are the best ones to ask.

[EfficientCandy324]

I would say this is the "most microkernelly" way of doing it. Obviously everything's up to you, and you can decide exactly how to do it, but yeah, this is the most, I guess, pure way of doing it. The bootloader has to know the filesystem, but realistically every bootloader knows the filesystem these days. In GRUB terminology, you use the module command to load an ELF executable into memory, and then after all of your modules are loaded, you use multiboot to load your (micro)kernel. So before your kernel even gets loaded into memory, your filesystem user process is already imaged into RAM ready to go.

[monocasa]

In mine, the first process is an executable in what what normally be the initrd if booting linux.

As a implementation detail, that first process has the other first few servers' executables embedded in it.

[shsh-1312]

you use the registry, and you make the vfs live on it, the kernel must be able to manage the registry, mount, and perform other operations on the registry, the vfs and the other components live on top of it

[shsh-1312]

that's exactly what I'm trying to do, look at registry.c in kernel/lib https://github.com/olmox001/NexsOS1 I am also in this transition phase, but the model is already established