You have Missed the Biggest problem with Multiboot.

You have Missed the Biggest problem with Multiboot.

[Peter Dolding]

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.

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.

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

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.

Peter Dolding

Re: You have Missed the Biggest problem with Multiboot.

[Marco Gerards]

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

Re: You have Missed the Biggest problem with Multiboot.

[Peter Dolding]

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

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

Re: You have Missed the Biggest problem with Multiboot.

[Marco Gerards]

Peter Dolding <oiaohm@bluebottle.com> writes:

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

We can't include a parser for every possible way to store
configuration data.  If you feel like your design is too restrictive
on you, you would have to either change the design or change the
loader.

You have to know that how to configure the kernel and modules that
have to be loaded is not a part of the multiboot standard.

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

Which licensing restrictions?

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

Why don't you just use an initrd or so like linux does?

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

You can just move the modules to some other location after loading.

--
Marco