[coyotos-dev] Drop multiboot module support?

Jonathan S. Shapiro shap at eros-os.com
Mon Mar 3 23:33:42 EST 2008


On Mon, 2008-03-03 at 20:17 -0800, Charles Landau wrote:
> At 10:36 PM -0500 3/3/08, Jonathan S. Shapiro wrote:
> >Am I missing anything here that would motivate continued support of
> >modules and/or initrd?
> 
> You might want to load the modules into a different location in RAM 
> than the kernel.

Even if multiboot is used, the kernel must already relocate the loaded
module out of the way, so the issue here would be intervening ROM images
that might prevent load altogether. My sense about this -- and I
acknowledge that this may be very naive -- is that if the preload module
gets this big on any system we presently know about, we have far bigger
problems to deal with.

Just as a data point, the current behavior of GRUB is to load the
modules just above the kernel image, so integrating the module into the
kernel image doesn't actually alter the load behavior.

For systems that stick us with an inconveniently placed ROM in the
middle, we can use the ldscript mechanism to specify the load address of
the loaded image independent of the kernel text/data load addresses.

So yes, I think you have identified a potential issue, but I think that
the ldscript mechanism can already address this issue.

> When booting from ROM, you may want to "load" the kernel into RAM, 
> but keep the modules in ROM until you need to access them.

We've looked at this, and our preliminary assessment is that the preload
module should always be loaded into RAM. A module that is loaded on
demand from ROM is not, by definition, a preloaded module. Modules that
are demand-loaded from ROM, if any, would be supported directly by an
in-kernel range load driver. Such regions need careful handling anyway,
since write-back to ROM is not supported.

Somewhat curiously, we have no present plans to use a ROM-loadable
module of the form that you describe.


shap



More information about the coyotos-dev mailing list