From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1F4Y6g-0005oZ-KA for mharc-grub-devel@gnu.org; Thu, 02 Feb 2006 01:38:14 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1F4Y6d-0005nS-R0 for grub-devel@gnu.org; Thu, 02 Feb 2006 01:38:11 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1F4Y6c-0005kT-0k for grub-devel@gnu.org; Thu, 02 Feb 2006 01:38:11 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1F4Y6b-0005k4-Ra for grub-devel@gnu.org; Thu, 02 Feb 2006 01:38:09 -0500 Received: from [209.144.225.72] (helo=fe3.bluebottle.com) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA:32) (Exim 4.52) id 1F4Y5O-0002cu-Dy for grub-devel@gnu.org; Thu, 02 Feb 2006 01:36:54 -0500 Received: from fe0.bluebottle.com (fe0 [209.144.225.92]) by fe3.bluebottle.com (8.13.4/8.13.4) with ESMTP id k126ZOqR023473 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 00:35:25 -0600 Received: from [211.26.68.8] (008.a.001.mar.iprimus.net.au [211.26.68.8]) (authenticated bits=0) by fe0.bluebottle.com (8.13.4/8.13.4) with ESMTP id k126Yhbl030548 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 2 Feb 2006 00:34:52 -0600 Message-ID: <43E1A5DD.5090303@bluebottle.com> Date: Thu, 02 Feb 2006 16:25:33 +1000 From: Peter Dolding User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: grub-devel@gnu.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV version 0.88, clamav-milter version 0.87 on fe0.bluebottle.com X-Virus-Status: Clean X-Trusted-Delivery: Subject: 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 06:38:13 -0000 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