Re: You have Missed the Biggest problem with Multiboot.

[Marco Gerards]

Peter Dolding <address@hidden> 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