From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1F4hXH-0006iP-9m for mharc-grub-devel@gnu.org; Thu, 02 Feb 2006 11:42:19 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F4hXA-0006fQ-6e for grub-devel@gnu.org; Thu, 02 Feb 2006 11:42:13 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F4hX4-0006eL-Rf for grub-devel@gnu.org; Thu, 02 Feb 2006 11:42:11 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4gX8-0000OL-FT for grub-devel@gnu.org; Thu, 02 Feb 2006 10:38:06 -0500 Received: from [199.232.41.67] (helo=mx20.gnu.org) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1F4ezA-0007Eb-OQ for grub-devel@gnu.org; Thu, 02 Feb 2006 08:58:57 -0500 Received: from [194.109.24.21] (helo=smtp-vbr1.xs4all.nl) by mx20.gnu.org with esmtp (Exim 4.52) id 1F4bp1-0007oE-VU for grub-devel@gnu.org; Thu, 02 Feb 2006 05:36:16 -0500 Received: from localhost.localdomain (mgerards.xs4all.nl [82.92.27.129]) by smtp-vbr1.xs4all.nl (8.13.3/8.13.3) with ESMTP id k12AaETX051176 for ; Thu, 2 Feb 2006 11:36:15 +0100 (CET) (envelope-from mgerards@xs4all.nl) Mail-Copies-To: mgerards@xs4all.nl To: The development of GRUB 2 References: <43E1A5DD.5090303@bluebottle.com> From: Marco Gerards Date: Thu, 02 Feb 2006 11:36:14 +0100 In-Reply-To: <43E1A5DD.5090303@bluebottle.com> (Peter Dolding's message of "Thu, 02 Feb 2006 16:25:33 +1000") Message-ID: <87k6ce59pd.fsf@xs4all.nl> User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: by XS4ALL Virus Scanner Subject: Re: You have Missed the Biggest problem with Multiboot. X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Feb 2006 16:42:15 -0000 Peter Dolding 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