Peter Dolding <[EMAIL PROTECTED]> 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 _______________________________________________ Grub-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/grub-devel
