Re: You have Missed the Biggest problem with Multiboot.

[Peter Dolding]

Marco Gerards <address@hidden>=| Please pardon the rough marking  Got this in 
digest.
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.

Grub is quite Generic but very restricting in some places.  Ok Multiboot 
modules.  Loading stacking all this can be bent to suit Reactos.  Different 
blocks have to be at different places this is not really that big of a problem. 
 Minor loss of speed.
The problem is the Config file.
kernel xxxx
module xxxx
module xxxx
Now this is the problem.  Reactos stores most it information on what driver to 
load on startup in the registry like Windows NT/2000/XP.  No method exist to 
allow the Config information to be acquired from a different source from what I 
can see.  For Reactos and some other OS's its better to get this from where its 
required.   Block of code from out side grub loaded to get the infomation looks 
like the best way.  Many different OS's could wish to store this infomation in 
different locations and files in different formats.  The stub is to process 
this to return the information GRUB requires so it can load the right modules.

> > 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?
Not some filesystems.  Zfs and the like that might be in use.

Maybe I missed it.  I saw no way to add new filesystem modules without 
replacing grub.
Ie prototype filesystem driver you might not wish to make it part of grub 
install at this time.
Or some filesystem not allowed to be in grub due to licence restictions.

> > 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).

Either Offer to a OS or to a stub to provide a list of stuff for grub to load.  
No read only filesystem required
to pull other information from the system just to load modules for a kernel so 
it can work.

The weakness of the multiboot is how can a OS developer provide a list of 
modules to load from location and format of the OS developers Choosing.  Ie a 
Restiction.  Modules loaded into the wrong memory locations can be dealt with.  
More control over Memory location of modules would handy.  No where near as 
problem causing for syncing between two different list of modules to load.

Peter Dolding