From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LqU86-0004iQ-Gr for mharc-grub-devel@gnu.org; Sun, 05 Apr 2009 11:19:26 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqU84-0004gt-Cb for grub-devel@gnu.org; Sun, 05 Apr 2009 11:19:24 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqU7z-0004f7-Pl for grub-devel@gnu.org; Sun, 05 Apr 2009 11:19:24 -0400 Received: from [199.232.76.173] (port=41704 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqU7z-0004f4-Nj for grub-devel@gnu.org; Sun, 05 Apr 2009 11:19:19 -0400 Received: from fg-out-1718.google.com ([72.14.220.156]:6502) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LqU7z-0005Jt-93 for grub-devel@gnu.org; Sun, 05 Apr 2009 11:19:19 -0400 Received: by fg-out-1718.google.com with SMTP id l27so127775fgb.7 for ; Sun, 05 Apr 2009 08:19:18 -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=jog3oV24i0HziAJJlCCswwSYfBzz5ZpZeraVw2GxFd8=; b=uedX6/yb7nI1cc7XgJtbz6fYQuOk0KpFffBW/6dK0gHiobBmm83HJi30ukIz1NM6aC IYGVwz/sdkHYWlf7ZjFKWRoG6tRF0Gewayolih8xcICERm+PDCoKk/u57xb5Mrcq3JX7 NNHYZgVUPJtkN+UloB4Ra3yKyiQSO5PzTRSdA= 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=jYQw177HW6eIAjtMquEVT/LIec8kfnPdWR7YOo2qs3ZcPrvqjl1kh2/p1aurc3iyXy eVnYG5VdYoeXOVQ6MFTEQskdnfQqqu2y7y9rpOmIO38vP7d5+vC3Ty2Cm8eB1mMEJXwg IdQdnqXt2n7URZjEpJNV444VVmF5aho8Yc6zo= Received: by 10.86.95.20 with SMTP id s20mr2366291fgb.77.1238944758164; Sun, 05 Apr 2009 08:19:18 -0700 (PDT) Received: from ?192.168.1.25? (240-88.62-81.cust.bluewin.ch [81.62.88.240]) by mx.google.com with ESMTPS id d4sm5995465fga.18.2009.04.05.08.19.17 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 08:19:17 -0700 (PDT) Message-ID: <49D8CBF7.2000705@gmail.com> Date: Sun, 05 Apr 2009 17:19:19 +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> <49D38446.6030302@gmail.com> <49D38692.9080201@nic.fi> <49D38C4C.4000407@gmail.com> In-Reply-To: <49D38C4C.4000407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit 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: Sun, 05 Apr 2009 15:19:24 -0000 On the IRC Yoshinori K. Okuji agreed that this move can be useful in cases like lvm+raid and luks. Any further oppositions? phcoder wrote: > I was thinking about something more finished like the possibility of > handling multiple preboot and to undo the operations in case of failed > or returned boot. Potentially it could be moved to a separate module but > it results in a reverse dependency and somewhat ugly code > Vesa Jääskeläinen wrote: >> phcoder wrote: >>> 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 >> >> Even if you add the preboot hooks there, it should only cause size >> affect in couple of bytes for uncompressed image. >> >> Like in following "sketch": >> >> ... >> >> preboot_handler_address: dd 0 >> >> ... >> >> cmp [preboot_handler_address], 0 >> >> je no_preboot_handler >> >> call [preboot_handler_address] >> >> no_preboot_handler: >> >> >> _______________________________________________ >> Grub-devel mailing list >> Grub-devel@gnu.org >> http://lists.gnu.org/mailman/listinfo/grub-devel > > -- Regards Vladimir 'phcoder' Serbinenko