From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lp26v-0003NT-Rc for mharc-grub-devel@gnu.org; Wed, 01 Apr 2009 11:12:13 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lp26u-0003NL-Mf for grub-devel@gnu.org; Wed, 01 Apr 2009 11:12:12 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lp26q-0003Mf-9r for grub-devel@gnu.org; Wed, 01 Apr 2009 11:12:12 -0400 Received: from [199.232.76.173] (port=42241 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lp26q-0003Mc-2I for grub-devel@gnu.org; Wed, 01 Apr 2009 11:12:08 -0400 Received: from mail-bw0-f167.google.com ([209.85.218.167]:44434) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lp26p-0008V2-GY for grub-devel@gnu.org; Wed, 01 Apr 2009 11:12:07 -0400 Received: by bwz11 with SMTP id 11so75454bwz.42 for ; Wed, 01 Apr 2009 08:12:06 -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 :content-type:content-transfer-encoding; bh=u5d59EKdt+gzWJivPYMv249myqUIddJVjYvmzMbpy9A=; b=ff6L/SYKSu5sB5XrDHPhzuj1o1XEwsQY6nyfimPammmqHUbubAm3apQqMFUs3PjQul Elo1cWO+uZB2ers5XJgJC/tJimdwsCc81CKYILUDN/O6GvfBF8Lojfpbem96w8rbzSOt mF05/qj9m5dtnOSeeQ8rr6kYR/2tLFMemN+FA= 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:content-type:content-transfer-encoding; b=Uf2FDk4/1oVn0ZwhScAV/KZ2h2qQEEyWglw4eH+pClFjX/lrWs2kfW5TfGsp/1zeOB kh+Q2KDZNNsgFZHKzy0LxPkRZgtMtC4AZQX30HloXWWzS2aZ458RXDA0UNp/ajE8T1jj tvXe6A8yHAfG/NUw8iyCIx08Ln2hM89grzhAc= Received: by 10.223.108.196 with SMTP id g4mr6281727fap.36.1238598726624; Wed, 01 Apr 2009 08:12:06 -0700 (PDT) Received: from ?82.130.79.102? (ifw-public-dock-102-dhcp.ethz.ch [82.130.79.102]) by mx.google.com with ESMTPS id h2sm19942fkh.9.2009.04.01.08.12.06 (version=SSLv3 cipher=RC4-MD5); Wed, 01 Apr 2009 08:12:06 -0700 (PDT) Message-ID: <49D38446.6030302@gmail.com> Date: Wed, 01 Apr 2009 17:12:06 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49C63395.9090304@gmail.com> <200904012252.26655.okuji@enbug.org> <20090401141932.GA28777@thorin> <200904012342.22787.okuji@enbug.org> In-Reply-To: <200904012342.22787.okuji@enbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Move loader.c out of the kernel 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: Wed, 01 Apr 2009 15:12:12 -0000 This usage case isn't the main target case. If you embed the loader (which tend to be quite big) then you already have an overhead from loader module. Why are you so concerned with overhead of boot.mod? But on the other hand this forces all the people in other cases to have boot code in core.img. I want to add preboot hooks and don't want increment size of kernel. multiboot.mod currently increases the size by around 11KB. And my patch doesn't restrict you from putting loader in core.img in any way Yoshinori K. Okuji wrote: > On Wednesday 01 April 2009 23:19:32 Robert Millan wrote: >> On Wed, Apr 01, 2009 at 10:52:26PM +0900, Yoshinori K. Okuji wrote: >>> On Tuesday 31 March 2009 17:56:24 phcoder wrote: >>>> With a new swing in normal.mod splitting I think we should reconsider >>>> this patch. It's useless to keep loader.c in kernel without boot >>>> command. IMO it should be moved either to a perate boot.mod (my >>>> preference) or to minicmd.mod (not a good option IMO) >>> As I said, rescue mode is not quite useful without any loader. So the >>> loader interface should be built into the kernel, and the boot command >>> should be as well naturally. >> This presses for more space into core.img, which is highly constrained >> (specially in weird combinations like raid + lvm or crypto in the future). >> >> Why is a loader so important for rescue mode? If the loader would work, it >> means you can read files, so it should be able to load the rest of modules >> as well. > > If some or all modules are trashed, no. Also, the user might be able to read > other partitions. > >> When user is dumped to rescue mode, usually (at least for reports I dealt >> with in debian) it means GRUB has a bug or didn't setup itself properly, >> and the /boot/ directory can't be accessed. A loader wouldn't help in >> these situations. > > And, the rescue mode does not help very much in this case. > >> Also, how do you determine which loaders belong in kernel? There can be >> many specialized loaders like the linux one. Or we could just put >> multiboot, but the Multiboot loader is quite complex already, and it still >> has room for growing. Maybe the answer is to write a very simple Multiboot >> loader and put that in kernel? > > That's up to the user IMO. For example, suppose this kind of scenario: > > - the user has a dual boot environment, say, GNU/Linux and Windows. > - she uses GRUB installed with the GNU/Linux. > - she has made something stupid in the GNU/Linux (e.g. rm -rf /). > > In the case of GRUB Legacy, this is the end. It's just unbootable, because > stage 1.5 may not boot anything besides stage2. > > In the case of GRUB 2, if the user has pre-loaded chainload.mod onto the > core.img, she can still boot the Windows. > > Honestly, I am more interested in making it possible to use GRUB for setting > up a very robust environment. For example: > > - the user installs a main OS and a rescue OS into a single machine. The > latter can be very compact (e.g. puppy, grml, etc.). > - she installs another boot loader into the partition for the rescue OS. > - she pre-loads chainload.mod in core.img. > > I think the chainloader is the most realistic, because it is the smallest > loader, and GRUB does not need to read a filesystem, thus no filesystem > driver is required for loading an OS. > > Every time I maintain a remote system, I feel the necessity of being prepared > for disasters (e.g. filesystem crashes). Rescue mode is one of the tools > required for this goal. > > Regards, > Okuji > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko