Re: You have Missed the Biggest problem with Multiboot.

[Marco Gerards <mgerards@xs4all.nl>]

Peter Dolding <oiaohm@bluebottle.com> writes:

> Funny as it seams its not the how it works exactly is the problem.
>
> Lets take Reactos for example.  Modules/drivers that must be loaded on
> boot are declared in the registry of their OS.
>
> Where in the current Grub can this be done.  In the Config File of
> grub.  A lot of OS's need to be able alter how this information.
> Inserting into the grub config is not always able to be done.  In
> Reactos it makes live harder because one copy would be in the registry
> and one copy would be in the grub boot and would have to kept synced.
> So for them it was simpler to develop their own boot loader than use
> Multiboot.

Sorry, but I do not understand what you are talking about.  Because I
do not know reactos, I have no idea what kind of information is
required by the kernel and how it handles this information.

> Really what is required is a OS setup stub.
>
> Stub returns list of modules and kernel to be used then Grub takes
> over and does the multiboot.  This is really just changing where you
> would get the information from.  Instead of the grub config file to
> where ever is best for the OS.

Please understand GRUB is quite generic.  You use modules in some way,
other OS developers use modules in a completely different way.  Can
you tell us how you use modules?  You would have to be more specific,
before we can reply to this.

> This is a extra feature.  Standard file system modules for grub.  So
> if I add a new OS using a different file system than currently
> installed grub I just tell grub to use file system xxxx xxxx being the
> location of the file system module.  Also passing access to a standard
> file system module threw to the stub.  Since stub should only be doing
> read only stuff and the file system module should only be read only it
> should not be a problem..

There are filesystem modules for GRUB so GRUB can read from almost any
filesystem.  So I assume what you mean has been implemented in GRUB 2,
or do I misunderstand you?

> Now if we could share standard file system modules with the other open
> source boot loaders would save a double up of work.
>
> OS developer with both parts are provided with a advantage at first
> they don't have to write file system modules in a boot code to get OS
> working only the read write file system driver of the OS.  And it
> should be less coding.

Do you mean you want GRUB to offer a filesystem interface to the OS?
That is simply not the goal of multiboot and not realizable in
practise without causing a lot of design problems.  Because of this
GRUB is able to read the files the OS requires (the multiboot kernel
and modules).

--
Marco