I'm at a point where I can decide what kernel design to go with. Which (in the sense of useability, codeability, and other important factors) is best?
I have a little idea of sorta a kernel where a healthy percent of the systems are directly in the kernel and some are implamented in "sub-system" (sub-system basic defination as processes like a microkernel. What will be in the kernel itself would be things like task management, non-system specific memory management, basic "compile in" drivers, and low level code that is/isn't specific to an archatechure.
Cheers, DH.
Microkernels and Monolithic kernels
-
Pype.Clicker
- Member
- Posts: 5964
- Joined: Wed Oct 18, 2006 2:31 am
- Location: In a galaxy, far, far away
- Contact:
Re:Microkernels and Monolithic kernels
well, that's much a matter of your preferences. Personnally, i'm trying to write Clicker so that the clients of a component use it the same way regardless of whether it's in userspace or in kernelspace.
I (personnally) also don't see the interrest of having things like the memory manager as a separate process, though the swapper could be (and afaik, it is even in Linux kernel).
I'm more going for an hybrid approach concerning filesystems and network stacks but this is yet to come ...
I (personnally) also don't see the interrest of having things like the memory manager as a separate process, though the swapper could be (and afaik, it is even in Linux kernel).
I'm more going for an hybrid approach concerning filesystems and network stacks but this is yet to come ...
-
dh
Re:Microkernels and Monolithic kernels
Well I'm thinking about going with my idea design as it's (theoritacly) a "perfect" microkernel/monolithic design (in my eyes at least).Pype.Clicker wrote: well, that's much a matter of your preferences. Personnally, i'm trying to write Clicker so that the clients of a component use it the same way regardless of whether it's in userspace or in kernelspace.
I (personnally) also don't see the interrest of having things like the memory manager as a separate process, though the swapper could be (and afaik, it is even in Linux kernel).
I'm more going for an hybrid approach concerning filesystems and network stacks but this is yet to come ...
I forgot to point out that the idea is that the sub-system is also in kernel mode so all the drivers in it are technically part of the kernel (hence why it's more-less both a monolith and micro ;P).
Cheers, DH.
-
aladdin
Re:Microkernels and Monolithic kernels
I also have the approach of a hybrid kernel : some basic componenets will remain in the kernel (such as low level memory manager, arch sp?cific code, scheduler), and others will be completely separated modules (running in user land)
but I have a little variant on which i'm actually working : i want to let the user choose to load or not internal kernel modules as well (using a configuration file), for example, we can imagine a kernel with two or more schedullers letting you to choose the scheduler to be used for a sp?cific need.
but I have a little variant on which i'm actually working : i want to let the user choose to load or not internal kernel modules as well (using a configuration file), for example, we can imagine a kernel with two or more schedullers letting you to choose the scheduler to be used for a sp?cific need.
-
mystran
Re:Microkernels and Monolithic kernels
My current interest is in microkernels. I'd like to build a small kernel with simple IPC system that's fast but practical. And maybe build some OS on top of that.
-
dh
Re:Microkernels and Monolithic kernels
@aladdin: my basic design has the concept of "twigs", "branches", "Trees", etc. Each is better at handeling more programs as it would have management code. As each is more advanced, they're bigger.
Re:Microkernels and Monolithic kernels
Hi,
IMHO the physical memory manager, the linear memory manager, the scheduler and code to handle critical errors (exceptions, kernel panic) should be in the kernel for performance/sanity reasons. It's hard to get the first process into it's own address space and spawn a thread for it otherwise. Also I see no benefit of having these things outside the kernel - it's not like you'd be able to replace any of them after boot anyway.
On top of this I've got "kernel modules" which run at cpl=0 in the kernel's part of the address space even though they use their own threads and address spaces. These modules are loaded directly from a boot image during boot and contain the basic functionality needed to get device drivers and things going, as well as providing the OS's security systems. None of them can easily be replaced after boot.
There are only 3 kernel modules. The "Primary User Interface" handles user login & passwords, and provides an interface between other code and user related devices (video, sound, keyboard, mouse, etc). The Primary User Interface uses a "user interface protocol" that is also used by GUIs and applications, so that an application connected to a GUI (e.g. running in a window) uses the same protocol as it would if it was connected directly the the primary user interface (e.g. running full screen). GUIs also use the same protocol to communicate with the Primary User Interface, and it's possible to have GUIs cascaded (where you've got a GUI running in a window of another GUI, running in a window of another GUI, up to 7 levels). If there's 2 keyboards and 2 video cards the Primary User Interface will spawn another thread to handle a second (completely seperate) user. If there's N keyboards and N video cards then you can have N users.
The "Virtual File System" handles file system security, mount/unmount, etc and provides an interface to all files (including a file cache) and any devices (except user related devices - video, sound, keyboard, mouse, etc).
Lastly there's "Device Manager" which handles all hardware resources (IRQs, IO ports, ISA DMA, etc), power management, device auto-detection and loading suitable device drivers. To do this the device manager uses CPL=0 for access to all hardware resources to scan every possible bus, where "bus" includes anything that can have other devices attached to it, except for SCSI controllers, IDE/ATA/ATAPI controllers and floppy controllers. This means that when a device driver is started it's automatically sent a list of resources that have been assigned to it. It also emulates IO ports, so the real IO ports used by a device can be changed without effecting/notifying the device driver (consider hot plug PCI devices and resource conflict resolution).
Everything else is a user-level multi-threaded process, including device drivers, GUIs, applications, etc.
Cheers,
Brendan
I've always liked the simple, consistant design of a pure micro-kernel, where as much as possible is a user-level process that can be dynamically loaded/unloaded & replaced. This model has a few practical problems though.mystran wrote: My current interest is in microkernels. I'd like to build a small kernel with simple IPC system that's fast but practical. And maybe build some OS on top of that.
IMHO the physical memory manager, the linear memory manager, the scheduler and code to handle critical errors (exceptions, kernel panic) should be in the kernel for performance/sanity reasons. It's hard to get the first process into it's own address space and spawn a thread for it otherwise. Also I see no benefit of having these things outside the kernel - it's not like you'd be able to replace any of them after boot anyway.
On top of this I've got "kernel modules" which run at cpl=0 in the kernel's part of the address space even though they use their own threads and address spaces. These modules are loaded directly from a boot image during boot and contain the basic functionality needed to get device drivers and things going, as well as providing the OS's security systems. None of them can easily be replaced after boot.
There are only 3 kernel modules. The "Primary User Interface" handles user login & passwords, and provides an interface between other code and user related devices (video, sound, keyboard, mouse, etc). The Primary User Interface uses a "user interface protocol" that is also used by GUIs and applications, so that an application connected to a GUI (e.g. running in a window) uses the same protocol as it would if it was connected directly the the primary user interface (e.g. running full screen). GUIs also use the same protocol to communicate with the Primary User Interface, and it's possible to have GUIs cascaded (where you've got a GUI running in a window of another GUI, running in a window of another GUI, up to 7 levels). If there's 2 keyboards and 2 video cards the Primary User Interface will spawn another thread to handle a second (completely seperate) user. If there's N keyboards and N video cards then you can have N users.
The "Virtual File System" handles file system security, mount/unmount, etc and provides an interface to all files (including a file cache) and any devices (except user related devices - video, sound, keyboard, mouse, etc).
Lastly there's "Device Manager" which handles all hardware resources (IRQs, IO ports, ISA DMA, etc), power management, device auto-detection and loading suitable device drivers. To do this the device manager uses CPL=0 for access to all hardware resources to scan every possible bus, where "bus" includes anything that can have other devices attached to it, except for SCSI controllers, IDE/ATA/ATAPI controllers and floppy controllers. This means that when a device driver is started it's automatically sent a list of resources that have been assigned to it. It also emulates IO ports, so the real IO ports used by a device can be changed without effecting/notifying the device driver (consider hot plug PCI devices and resource conflict resolution).
Everything else is a user-level multi-threaded process, including device drivers, GUIs, applications, etc.
Cheers,
Brendan
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.
-
mystran
Re:Microkernels and Monolithic kernels
While I'd probably put the virtual memory manager (but NOT pager) and scheduler into kernel, there is one big advantage in having everything from pagers to process managers to security subsystems in userspace: If you pay attention to this when designing the system, you can run several, possibly different systems on top of the same kernel at the same time.
-
AR