From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OOdMD-0000Gl-8r for mharc-grub-devel@gnu.org; Tue, 15 Jun 2010 17:07:41 -0400 Received: from [140.186.70.92] (port=34151 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOdMA-0000Ec-06 for grub-devel@gnu.org; Tue, 15 Jun 2010 17:07:39 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOdM8-0006p4-H9 for grub-devel@gnu.org; Tue, 15 Jun 2010 17:07:37 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:34704) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOdM8-0006ot-Au for grub-devel@gnu.org; Tue, 15 Jun 2010 17:07:36 -0400 Received: by wwb34 with SMTP id 34so5598600wwb.0 for ; Tue, 15 Jun 2010 14:07:31 -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=OOtInrMmSeVrJWX+VIcm+JyZrdoytH5iBvp8EAbD3YQ=; b=b6pi7bp9VG8E0pEE3wY5d/lzcq1jCNXxIE9cKFbkMG+H7+f0zY0elhinoY99/ooynm NOf2Yo9k4KVk3/OiR6Pg1enu/jEQtPFXlXaq6ElJBhD4LbWKXlAvKjBhW4eUTTdXvfBC GZ08rLQhhxdZulnL0Lt3AnG9EN96xm9/CoSjY= 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=rbu5prEjUoruXLLzqGaIkcI8HAJqdtUeACWteOERwiG0nKjMyO+tvpBH1wuuf3z9KL bLf+s8s9IkOFOu0KqrvPDtC67ryQTyXTeDucZvfZPqOJwvUTGgOLONGuyqd2x8UhJWOF abqA536IRRTLA2mfxI7MAInpC2PxpBQQ4YZKE= Received: by 10.227.133.70 with SMTP id e6mr7803550wbt.148.1276636051522; Tue, 15 Jun 2010 14:07:31 -0700 (PDT) Received: from [192.168.1.50] (c2433-1-88-160-112-182.fbx.proxad.net [88.160.112.182]) by mx.google.com with ESMTPS id b17sm48843043wbd.1.2010.06.15.14.07.30 (version=TLSv1/SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 14:07:31 -0700 (PDT) Message-ID: <4C17EB9E.9050309@gmail.com> Date: Tue, 15 Jun 2010 23:07:42 +0200 From: =?ISO-8859-1?Q?Gr=E9goire_Sutre?= User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9) Gecko/20100515 Icedove/3.0.4 MIME-Version: 1.0 To: The development of GNU GRUB References: <4C13B6A8.7060102@gmail.com> <4C13C33B.4090302@gmail.com> <4C15044D.9050608@gmail.com> <20100614113702.GN21862@riva.ucam.org> <20100614132536.GO21862@riva.ucam.org> <20100614150251.GA19053@riva.ucam.org> <4C1651BF.9010306@gmail.com> <20100614164310.GQ21862@riva.ucam.org> <4C166306.2030405@gmail.com> <20100615112111.GW21862@riva.ucam.org> In-Reply-To: <20100615112111.GW21862@riva.ucam.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: Which partitioning schemes should be supported by GRUB? X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 15 Jun 2010 21:07:39 -0000 On 06/15/2010 01:21 PM, Colin Watson wrote: >> A possible solution would be to use the multiboot-command line. AFAIK, >> the boot_device field of the multiboot information structure is supposed >> to pass this kind of partition information, but you cannot specify the >> partmaps in this field, hence its interpretation is ambiguous. > > That would potentially allow a user to override things, but doesn't help > with users who don't change their configuration. Unless the user > explicitly configures things, boot_device is all we've got. Ok. > Thus, I guess we end up with a two-part fix: > > 1) Honour key=value pairs in the multiboot command line when booting > GRUB itself as a multiboot image. These would simply become > environment variables. This would be nice. > 2) If multiboot_trampoline needs to change install_dos_part or > install_bsd_part based on the value of boot_device in the MBI, then > we know that the drive/partition part of prefix (which was > calculated in the same way as install_dos_part and install_bsd_part > when grub-setup was run) is now invalid and should be ignored. > This fact needs to be passed on to make_install_device. Since the command-line processing of the MBI is done after startup.S (in grub_machine_init()), - the MBI (only the relevant portions for simplicity) needs to be copied to a safe place. The patch does it at the end of grub_machine_init(), but I'm afraid this might be too late: the MBI may have been overwritten before we reach that point. Or is the code (startup.S and grub_machine_init()) designed to guarantee that all memory writes are in safe locations, outside of the whole MBI? - couldn't the complete processing of the MBI be performed in the same place, i.e. grub_machine_init()? The assembly multiboot part would only check whether GRUB was booted by multiboot, and set (or copy) the MBI in that case. Then the procedure to set grub_prefix would be coded in one place. This would require though, for multiboot, to get grub_boot_drive from the boot_device field (the current assembly code takes care of this). > void > grub_machine_init (void) > { > @@ -214,6 +279,15 @@ grub_machine_init (void) > if (! grub_os_area_addr) > grub_fatal ("no upper memory"); > > + if (startup_multiboot_info) > + { > + /* Move MBI to a safe place. */ > + grub_memmove (&kern_multiboot_info, startup_multiboot_info, > + sizeof (struct multiboot_info)); Moving the MBI is more complex, since the structure contains pointers to other structures (themselves containing pointers etc.). But in our case it's not too painful since we only need to copy the struct multiboot_info and the string pointed to by its cmdline field (and set the field to the new address). Grégoire