Mixing mono and micro

[casnix]

I was pondering what to do to make a more unique OS (unique or complex, not sure which), and I got an idea: A monolithic kernel within a microkernel. Such as:
cstage1 is booted by grub. cstage1 should only be able to mount the initrd, load, and execute cstage2 (the monolithic kernel) without setting up system calls
cstage1 loads and executes cstage2 out of the initrd, and
cstage2 sets up system calls and then loads specific modules for the microkernel part.
A bit like a multistage bootloader but with the kernel instead. Do you think it would be possible? Do you think it would be a bit inefficient? A memory hog? Also, if you've got any ideas, I'm welcome to suggestions.

P.S. Sorry for any previous troubles.

[Chandra]

I'm not sure if such design carries any advantages (other than uniqueness, of course).
Basically, the kernel model you choose depends upon the requirement for your OS so, implementing such design is recommended only if you have to.

Afterall, requirement gives birth to invention.

Cheers.

[gravaera]

I was pondering what to do to make a more unique OS (unique or complex, not sure which), and I got an idea: A monolithic kernel within a microkernel. Such as:
cstage1 is booted by grub. cstage1 should only be able to mount the initrd, load, and execute cstage2 (the monolithic kernel) without setting up system calls
cstage1 loads and executes cstage2 out of the initrd, and
cstage2 sets up system calls and then loads specific modules for the microkernel part.
A bit like a multistage bootloader but with the kernel instead. Do you think it would be possible? Do you think it would be a bit inefficient? A memory hog? Also, if you've got any ideas, I'm welcome to suggestions.

P.S. Sorry for any previous troubles.

Hi,

if I understand correctly: you set up specific boundaries for "stages", but if you think about it, "stage1" has parser code to extract files from your initrd format. So in the end, stage1 is essentially a bootloader that refuses to load things from disk, and instead prefer to redundantly load the kernel from an initrd image which was loaded by the bootloader...when the bootloader could have loaded a kernel image instead, along with the initrd, and move into the kernel immediately instead of going through a redundant "stage1" again.

Next, stage2 is your kernel, which is a standard hybrid kernel (debatable, not interested in debating it though), where you have a mix of monolithic's in kernel and microkernel's load as needed. If you take out "stage1", you end up with a normal hybrid kernel, nothing remarkable about it.

Is it possible, of course Inefficient? Nothing about the design is remarkably suboptimal, so no Memory hog, again, no, and as far as suggestions go, maybe take away the "stage1" part? Of course, it's all design in the end anyway, so it hardly matters.

--Have fun
gravarera

[rdos]

I'm not sure if my kernel is mono or micro or whatever. Sometimes I move-out code to device-drivers, and sometimes I move device-drivers back into the "kernel". At least I suppose the executable file that i call "kernel.exe" is the kernel.

Anyway, I supoose the distinction has to do with interfaces. Both kernel and device-drivers share the callgate interface that I've written about in the "code patching with SMP" thread. So, in this sense, the image I call "kernel.exe" is both the kernel and also partly a device-driver because it uses it's own exported callgate interface itself. In a few cases I do link near-versions of the interface because some functions might get called before the callgate interface is properly setup, but that is only very few cases.

And when I load my OS with GRUB, I have a "kernel image" that I call "grubload.exe", that fools GRUB into believing it is something it can load directly. Grubload.exe kills GRUBs 32-bit flat memory model and sets up the ordinary 16-bit protected mode memory model that is required in order to load the real kernel (kernel.exe). The real OS image is passed to GRUB as a module.

[casnix]

Yes, I suppose that it would be a hybrid kernel. I wouldn't need to create a stage that goes back into real mode (although that's pretty cool to have a modular kernel in 16 bit

I guess one of practical uses of a multi stage kernel would be to choose which stage 2 i would use and setup the required modules for that stage, which could all be done without a stage 1 like graverera said.

Thank you,

casnix

[rdos]

Yes, I suppose that it would be a hybrid kernel. I wouldn't need to create a stage that goes back into real mode (although that's pretty cool to have a modular kernel in 16 bit

I don't need to go all the way back to real-mode. It is enough to just create the 16-bit selectors that the kernel expects to be invoked from. I also fill-in some basic memory information of where to search for modules, and where RAM is located. The device-drivers have signatures and CRC-checksums, so the kernel finds & starts them by searching for them in memory.

It is only in the crash debugger that I go all the way back to real-mode in order to reset the video card. It is cool to be able to take-down a paged, multicore system from an ISR in a controlled way

I guess one of practical uses of a multi stage kernel would be to choose which stage 2 i would use and setup the required modules for that stage, which could all be done without a stage 1 like graverera said.

When I do a harddrive boot of RDOS, I first have the boot-sector which loads a second stage image. This second stage collects information about memory, checks the boot-device flle system for possible RDOS images, lets the user select one of them, loads it into some memory area, sets up a 16-bit protected-mode environment, finds the kernel in memory, sets up selector 0x30 to point to the kernel, and then jumps to the kernel initialization entry-point. This second stage does the same thing as grubload.exe when booting with GRUB.

[casnix]

Okay, that's really cool xD