ShackaN <shackan@...> wrote:
> I've been told that BeOS (and consequently Haiku) is not a =B5-kernel
> operating system, but rather a "highly modular" one, thus, AFAIK,
> although the core functionalities reside in the kernel, many
> addictional features will be imported from "external" modules; I had=20
Right, although most of the crucial things, like the VFS and others,=20
are built-in as well.
> look at your website, but I could find no info about how the module
> loader works (or better, how you planned to make it work :) even if
> it's such an important part of the os, so here is my question for you
> kernel-hackers : WHEN does the kernel "know" that he needs some
> additional module? WHERE will the kernel look for such a module
> (inside a directory tree, inside a "pseudo-registry" =E0 la windows,
> whatever...) ? HOW does the kernel recognize that the found module is
> viable to carry out the needed task? HOW does the kernel internally
> load modules? and.. the "modules" are supposed reside in user- or
the first modules are loaded by the boot loader and handed over to the=20
kernel. Basically, the boot loader recognizes the environment, and then=20
loads the appropriate modules, so that the kernel can access the boot=20
But modules are also load during runtime, many of them during=20
initialization, some later - whenever the kernel decides to look out=20
for modules. For example, when an application tries to open a sound=20
device, the kernel will start looking for such modules at this point,=20
and not earlier.
all modules can be found under add-ons/kernel/. But this is not a flat=20
directory, it's a hierarchy organized by exported functionality. For=20
example, you'll find network drivers under a certain directory which is=20
different from that of a graphics driver.
Also, often modules directly ask for other modules, either by providing=20
their full interface name, or by asking for a specific feature set (ie.=20
tell the kernel to look in a specific directory only).
For Haiku, we'll extend this a bit to be able to recognize the drivers=20
needed for a specific hardware directly, ie. by providing a mapping=20
from the PCI device ID to a certain module, and that's also how the=20
boot loader will be able to know these things. BeOS itself always scans=20
the whole graphics driver directory when the app_server is asking for=20
some output device.
already answered above.
It's not a micro kernel, and therefore, kernel modules run in kernel=20
space. There exist some sort of hybrids that have parts running in=20
userland and another small part in the kernel (ie. graphics drivers do=20
it this way), but the kernel cannot do this alone.