well, i can offer a few of my research on modules ...
http://clicker.sourceforge.net/ideas/kds-overview.htmlhttp://clicker.sourceforge.net/docs/cak ... rview.htmlhttp://clicker.sourceforge.net/docs/tea ... ormat.htmlhttp://clicker.sourceforge.net/forums/i ... hreadid=17Quote:
can it put the device driver image wherever it wants, within reason?
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)
Quote:
Can the driver image be a flat binary ?
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
Code:
localkmalloc=KernelContext->lookup("kmalloc");
KernelContext->register("hard_disk",&driverstruct);
but
- that's a pain to maintain and debug
- each module/driver needs to implement its own linker, which is a waste of space.
Quote:
If the driver image is relocatable (or if any program image is relocatable) how does the kernel fix up the addresses in memory?
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