[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: You have Missed the Biggest problem with Multiboot.
From: |
Marco Gerards |
Subject: |
Re: You have Missed the Biggest problem with Multiboot. |
Date: |
Thu, 02 Feb 2006 11:36:14 +0100 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Peter Dolding <address@hidden> 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