From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1KCWRC-0007ms-9O for mharc-grub-devel@gnu.org; Sat, 28 Jun 2008 05:09:43 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KCWR4-0007k4-0i for grub-devel@gnu.org; Sat, 28 Jun 2008 05:09:35 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KCWR1-0007jH-IL for grub-devel@gnu.org; Sat, 28 Jun 2008 05:09:32 -0400 Received: from [199.232.76.173] (port=57327 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KCWQz-0007j4-Rs for grub-devel@gnu.org; Sat, 28 Jun 2008 05:09:30 -0400 Received: from mta-out.inet.fi ([195.156.147.13]:34623 helo=kirsi1.rokki.sonera.fi) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KCWQy-00036N-UQ for grub-devel@gnu.org; Sat, 28 Jun 2008 05:09:29 -0400 Received: from [127.0.0.1] (88.193.32.97) by kirsi1.rokki.sonera.fi (8.5.014) id 483E837C015C30A7 for grub-devel@gnu.org; Sat, 28 Jun 2008 12:09:21 +0300 Message-ID: <4865FFC6.8070804@nic.fi> Date: Sat, 28 Jun 2008 12:09:26 +0300 From: =?ISO-8859-1?Q?Vesa_J=E4=E4skel=E4inen?= User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: The development of GRUB 2 References: <1214601899.9513.58.camel@dv> In-Reply-To: <1214601899.9513.58.camel@dv> X-Enigmail-Version: 0.95.6 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-kernel: by monty-python.gnu.org: Linux 2.6 (newer, 3) Subject: Re: [RFC PATCH] Sector 2 of non-embedded core.img: write early or patch later? 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: Sat, 28 Jun 2008 09:09:35 -0000 Pavel Roskin wrote: > Hello! > > We have a serious problem with installing onto partitions (e.g. > grub-install /dev/sda1) and drives with geometry that doesn't leave > enough space for core.img to be embedded before the first partition. > While it's not a desirable configuration, it should work, but it > doesn't. > > Either we should write sector 2 before the core.img is checked for > readability or we should delay patching sector 2 in memory until the > verification is done. Otherwise, the verification will fail. > > Delayed patching changes nothing in terms of I/O but needs a longer > patch and won't scale well if we want to put more information into > sector 2, as we'll need to cache more data. Why not make a structure that holds every modification information that needs to be done ("configuration block"). And then you provide core.img and variable filled with configuration information to patch function that modifies core.img properly. This way you only need to write this once. With this you can either modify compare or patch two copies of the images with same configuration information.