OSDev.org

When a kernel has been loaded and needs to load device drivers, can it put the device driver image wherever it wants, within reason? For example, as long as it's out the way of the kernel? How then does it use the device driver? Presumably it needs to know the addresses of the functions within the driver, like DeviceSetup() or whatever. Can the driver image be a flat binary? (If it uses kernel routines it would need to be linked, right?) If the driver image is relocatable (or if any program image is relocatable) how does the kernel fix up the addresses in memory? Does it trap each memory access of the program, and add the base virtual address to the offset of whatever it wants within its own image? How about when it wants to access routines within the kernel? Does it trap them too and add the kernel's base address to the offset?

Thanks!

As my OS is not like most on this forum ( It's more of a specialist OS) ,It may not be of much help, But i have put the standard drivers like vesa,atapi,floppy etc, in the kernel as inc files.

ASHLEY4.

well, i can offer a few of my research on modules ...
http://clicker.sourceforge.net/ideas/kds-overview.html
http://clicker.sourceforge.net/docs/cak ... rview.html
http://clicker.sourceforge.net/docs/tea ... ormat.html
http://clicker.sourceforge.net/forums/i ... hreadid=17


Depending on what your kernel is able to do on its own, the answer will be different. But for ease of management, it's a good practice to have modules based under a precise directory (at least) in a file system and a disk that the kernel can access without the help of modules that are there. In Clicker, early "bootstrap" modules are provided by the bootloader in a ramdisk using a very simple read-only filesystem (SFS)


That wouldn't be wise. Of course you could say "my module is a flat binary which starts with a jump to "init()" function which will receive a KernelContext structure (allowing it to access all the kernel function) and which will do the bindings by calling

but

• that's a pain to maintain and debug
• each module/driver needs to implement its own linker, which is a waste of space.

Basically, the driver must include a relocation list that will tell at which memory locations the effective base address should be added. That list is usually created by the compiler, then it's up to you to put it in a form you prefer...

Hope That Helps.

Feel free to bug me again if you wish more info.
I also suggest you give a look to "linker and loaders" e-book to learn more about such techniques

In dex-os I use DLLs to load my device drivers into memory. Since the dex-os module loader is capable of patching imported functions, I simply use specific names for the driver entry points. Like Pype said, passing structs containing pointer to functions is messy (yes, dex-os does this to some degree) but there's no harm to using it at this early stage until you develop a 'sexier' driver interface. Currently dex-os uses relocatable DLL's since drivers are placed in a single memory space. You could refer to my module loader (pe_moudle.c/module.c) if you like or my device manager (dex32_devmgr.c).

Thanks very much everyone, and Pype.Clicker for loads of useful reading matter!

I'm getting the strong impression that the most useful drivers should be in the kernel, i.e. disk, keyboard and mouse, at all times. The bootloader should suck in the kernel, linked in with disk driver and all, and then additional modules can be found in well-known places on disk in the OS's filesystem. A small, bare kernel could even have a non-fancy IDE disk driver (i.e. no evelator algorithms or anything, just the bare minimum), use that to access the disk after switching into 32-bit pmode, then replace that with the more sophisticated IDE disk driver if it's present...

... then again, I'm going with having the drivers compiled into the kernel.

My kernel is going to take in additional modules using a similar approach to Pype, but the initial module set is just an archive (or filesystem, irrelevant) of normal modules that are loaded upon system start. The set is composed of all modules that were loaded at shutdown last time. If this system works correctly, all normal boots (no hw change) should be instantaneous, no PnP driver searches or anything.

My kernel is only going to contain the core kernel. This way it's possible to change the entire function of your machine without recompiling the kernel, or even having the source to it for that matter.