Modular Kernel: Difference between revisions

Jump to navigation Jump to search
no edit summary
[unchecked revision][unchecked revision]
No edit summary
 
No edit summary
Line 1:
{{Convert}}
 
!! ==What is a Modular Kernel ?==
''this is just under construction and collecting threads for now. It will then join the "microkernel, exokernel and monolithic kernel" in design category''
 
!! What is a Modular Kernel ?
 
A modular kernel is an attempt to merge the good points of kernel-level drivers and third-party drivers. In a modular kernel, some part of the system core will be located in independant files called _modules_ that can be added to the system at run time. Depending on the content of those modules, the goal can vary such as:
Line 13 ⟶ 11:
The basic goal remains however the same: keep what is loaded at boot-time minimal while still allowing the kernel to perform more complex functions. The basics of modular kernel are very close to what we find in implementation of _plugins_ in applications or _dynamic libraries_ in general.
 
!! ==What dodoes a Modular Kernel look like ?==
 
There are several components that can be identified in virtually every modular kernel:
;the core
;__the core__: this is the collection of features in the kernel that are absolutely mandatory regardless of whether you have modules or not.
;__the modules loader__: this is a part of the system that will be responsible of preparing a module file so that it can be used as if it was a part of the core itself.
;the modules loader
;__the kernel symbols table__: This contains additionnal information about the core and loaded modules that the module loader needs in order to _link_ a new module to the existing kernel.
;__the modules loader__: this is a part of the system that will be responsible of preparing a module file so that it can be used as if it was a part of the core itself.
;__the dependencies tracking__: As soon as you want to _unload_ some module, you'll have to know whether you can do it or not. Especially, if a module _X_ has requested symbols from module _Z_, trying to unload _Z_ while _X_ is present in the system is likely to cause havoc.
;the kernel symbols table
;__modules__: Every part of the system you might want (or don't want) to have.
;__the kernel symbols table__: This contains additionnal information about the core and loaded modules that the module loader needs in order to _link_ a new module to the existing kernel.
;the dependencies tracking
;__the dependencies tracking__: As soon as you want to _unload_ some module, you'll have to know whether you can do it or not. Especially, if a module _X_ has requested symbols from module _Z_, trying to unload _Z_ while _X_ is present in the system is likely to cause havoc.
;modules
;__modules__: Every part of the system you might want (or don't want) to have.
 
 
!!== How can such a system boot in first place ?==
 
Modularization must be done within certain limits if you still want your system to be able to boot. Pushing _all_ the filesystems and device drivers (including boot device driver) into module will probably make the boot time a hard time. Following solutions can however be used:
* The kernel is provided with an extremely simple [file[File systemSystems|Filesystemsfilesystem]] (e.g. SCO's BFS) driver and that filesystem contains modules to access the rest of system storage (e.g. module for EXT2, [[ReiserFS|reiser]], FAT, NTFS ...).
* The kernel comes with a built-in _nativenative file system_system driver and other storage modules as well as primary configuration files should be stored using that native filesystem. This was the approach followed by Linux, and as soon as some people decided to have [[ReiserFS|reiser]] everywhere, ext2-fs only kernels start having trouble on some machines.
* The bootloader knows it should not only load the _kernel_ but also a collection of pre-configured modules so that the kernel only needs to check those pre-loaded modules and initialize them to access other modules and primary configuration files. This basically means that your bootloader is somehow an OS of its own such as [[GRUB] ;-)]
 
Anyway, ramdisk drivers and dedicated boot partitions/reserved sectors will be your friends.
 
==See Also==
 
===Threads===
 
*[Design of a basic module loader|Forum:6962]
----
*[Calling a function knowing its name|Forum:6768]
 
*[DesignIdeas offor a basic module loaderIPC|Forum:69626604]
*[CallingCoff ai386 function knowing its namerelocations|Forum:67686443]
*[IdeasDevice forDrivers IPCInterface|Forum:66046397]
*[CoffLoading i386Drivers relocationsinto Kernel|Forum:64435895]
*[Design & Implementation of Extensible OS|Forum:5841]
[Device Drivers Interface|Forum:6397]
[Loading Drivers into Kernel|Forum:5895]
[Design & Implementation of Extensible OS|Forum:5841]
Anonymous user
Cookies help us deliver our services. By using our services, you agree to our use of cookies.

Navigation menu