[coyotos-dev] Drop multiboot module support?

[Christopher Nelson]

No, I agree.  We just mapped the modules into their own memory spaces and
ran them as full processes.  I don't see why you couldn't do the same thing
using your approach.

The only benefit that you might miss out on, is that using grub (or similar)
you could stop the boot process and specify a different or additional module
to load with the kernel.  Probably the only situation that is really vital
would be loading some driver that allows you to boot into an emergency
repair mode using an otherwise unsupported mass storage device for the
filesystem.

On Wed, Mar 5, 2008 at 8:38 AM, Jonathan S. Shapiro <shap at eros-os.com>
wrote:

> On Wed, 2008-03-05 at 08:17 -0500, Christopher Nelson wrote:
> > The one use I have had for them involves loading user-space drivers at
> > boot time.  Probably you have some other method to do this, but it
> > worked well to load them this way for me.  Especially the disk driver.
> > It avoids chicken and the egg problems.
>
> That is how we intended to use it as well. Note, however, that the
> initrd (driver set) image and the kernel image must share a common
> version number, so the two are closely tied. The main advantage to
> separating initrd is that you can rebuild the initrd file without
> touching the kernel file.
>
> I think this can be done sufficiently well with coymerge. Let me explain
> how coymerge works, and let's see if you agree:
>
> 1. At kernel link time, we perform a full (static) link of the kernel
> image to check for any unresolved symbols. This is done for debugging
> only. Having done it, we then perform a relocatable link (using ld -r).
> The resulting kernel image is a .o rather than an executable.
>
> 2. We bundle the mkimage.out file into a loadable section in a second .o
>
> 3. When we are ready to merge them, we simply link these two .o files to
> form a combined image. The resulting image is relocated, and is directly
> executable.
>
>
> So the main difference seems to be the last step where we combine the
> files. From a functional perspective, I don't see anything that the
> initrd mechanism can do that we cannot do here.
>
>
> What do you think?
>
>
> shap
>
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.coyotos.org/pipermail/coyotos-dev/attachments/20080305/e4f7dd5d/attachment.html