From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KcJIN-0006n6-D6 for mharc-grub-devel@gnu.org; Sun, 07 Sep 2008 08:23:11 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KcJIJ-0006mF-Fs for grub-devel@gnu.org; Sun, 07 Sep 2008 08:23:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KcJIG-0006lZ-JM for grub-devel@gnu.org; Sun, 07 Sep 2008 08:23:05 -0400 Received: from [199.232.76.173] (port=48445 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KcJIG-0006lU-9L for grub-devel@gnu.org; Sun, 07 Sep 2008 08:23:04 -0400 Received: from fg-out-1718.google.com ([72.14.220.158]:64319) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KcJIF-00036P-RJ for grub-devel@gnu.org; Sun, 07 Sep 2008 08:23:04 -0400 Received: by fg-out-1718.google.com with SMTP id l26so1175364fgb.30 for ; Sun, 07 Sep 2008 05:23:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :x-enigmail-version:content-type:content-transfer-encoding; bh=+BOj+I88APr32BGL8eU3TSEqNKHu0l5xnqhheAe+0Uo=; b=V1ww437HCu1xTr1iprrnu5KPiJ5Y2LbVWH35r1mR/kyj2QirRl2nncjZTRSHTeYXkM 2HYZzeXM0OztiVFLFT4fvQrOmr0pB51ILmoOmGHvt/kzTArgb5XC7yV8t7C1rDQLm5W6 WTAn4ACBvQzefRg9jK4o+rS0QY9W1fRXXRxZ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:x-enigmail-version:content-type :content-transfer-encoding; b=jhhbOgx/9xBKNA447/o3XyGQNqJP+5/YcgZaOnfnUoNLx3K+RNgQT57zxA0FwZIP3L OsyMKpdyBg1fBOFtokuTUmvX03iaUdoa3JU5ZenM5xjunrKd2HRBH8AnyTvSXvGxFPyc pcKVGlLi0OtUeKWt3EP4INMW/XDymokvrqYu4= Received: by 10.86.27.19 with SMTP id a19mr10356002fga.56.1220790182852; Sun, 07 Sep 2008 05:23:02 -0700 (PDT) Received: from ?192.168.1.15? ( [83.77.153.96]) by mx.google.com with ESMTPS id e20sm3228262fga.1.2008.09.07.05.23.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 07 Sep 2008 05:23:01 -0700 (PDT) Message-ID: <48C3C7A1.3080200@gmail.com> Date: Sun, 07 Sep 2008 14:22:57 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.16 (X11/20080724) MIME-Version: 1.0 To: The development of GRUB 2 References: <48C16C17.2000803@gmail.com> <20080906112003.GA14991@thorin> <48C31F5F.6060808@gmail.com> <48C381EF.3070703@nic.fi> <48C3B666.1060605@gmail.com> <48C3BD32.5050109@nic.fi> In-Reply-To: <48C3BD32.5050109@nic.fi> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 2) Subject: Re: [RFC] general-usage real-mode loader 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: Sun, 07 Sep 2008 12:23:08 -0000 Vesa Jääskeläinen wrote: > It is true that code is withing grub's i386 kernel. But other than that > same mechanism can be used to load kernel. After all kernel will take > over the computer after it has started and it is not returning back > anymore (eg. stack is not anymore there to be restored). > In this case my rmkern helper can use this mechanism but the problem is then that the rmkern should be able to choose where to put RM helper since some OS need specific places in memory to be filled with specific values > I would prefer that if we are going to give custom register > configurations for kernel then they all should use same structures for > storing registers. > > But anyway... Did you have some good examples where this functionaly > would be needed :) ? For now we have specialized loaders that prepare > system for any special OSes that needs to be supported. Especially how > do you know what registers to fill or better yet, how user will provide > this information so OS can be loaded. I thought that this function can be used as general helper for any kernel that needs to be launched in RM. In that cases RMkern functionality is used by OS-specific wrapper which knows what to put in the registers Usage cases: 1) chainloader 2) zbeos: BeOS and haiku. BeOS has a good functionality for booting from loopback but for this you need floppy, windows 9x/me or dos. On my laptop I have neither. But zbeos (BeOS and Haiku middle-loader) is really easy to load. 3) ecomstation: eCS is able to load from JFS but needs a specialized loader to be installed on its own primary active partition. I think GRUB should be able to load it directly. But perhaps also exporting of GRUB functions to ecomstation is needed (this is discussed in another thread, I'll write there later) 4) DOS/Win9x and freedos. Especially the second one. They use extended chainloader functionality found in grub4dos. With rmkern loading freedos kernel should be really easy. 5) Loading winnt (ntldr) and winvista (bootmgr) 6) Many other different proprietary and free OS. I don't know enough about them to say that this or that one can benefit from it but suppose many OS can be booted easier and more reliable with this functionality. 7) rmkern command. Experienced users, hobbysts and OS-developpers can enter manually the state in which they want their kernel to be loaded. May be handy also for reverse engineering > > If there is a need for specialized loader please provide some details > where those are needed and what is required from GRUB in order to > support that. If there is possibility to use multiboot then that would > supersede need for specialized loader. Some OS have their reasons not to support multiboot. E.g. haiku and freedos stick very near to their goal of reimplementation beos/dos and as such they don't want anything that would be better Vladimir 'phcoder' Serbinenko