From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OP24X-0004RY-QT for mharc-grub-devel@gnu.org; Wed, 16 Jun 2010 19:31:05 -0400 Received: from [140.186.70.92] (port=59209 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OP24V-0004ND-9w for grub-devel@gnu.org; Wed, 16 Jun 2010 19:31:04 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OP24U-0005S2-1p for grub-devel@gnu.org; Wed, 16 Jun 2010 19:31:03 -0400 Received: from mail-ww0-f41.google.com ([74.125.82.41]:35901) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OP24T-0005RW-Tu for grub-devel@gnu.org; Wed, 16 Jun 2010 19:31:02 -0400 Received: by wwb34 with SMTP id 34so6706368wwb.0 for ; Wed, 16 Jun 2010 16:31:00 -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=f9UTUIxpADq73cH3MmYMyZC50h1FSqy4a0heQkXS+TI=; b=agi4d9MCVN2DSmEFCdz/W8++ngWHLyP/aE1m1sQn96Ft+wsSoPIS1vdrlMlbw4Qpxf zLNGOs1rm2IQaMsaynIrgLfHsgPEe3N0jjXytAs6Zp0KHxBRRuyCmew3+ZrifRAx4O8L SQmXhrC0VVbO4Zpos11OEZT1Dm4m9onEsIOao= 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=Sep8k6De/OsCDjeIJ6uYrWEmNMuhF/uuVrvOjfy6elpMy2YKR1PePicbt3Cd027lIn 5iztSH6Gn2T6jEU0LL5ifgrGQoDOeWPDomrWUsPvq3M9VQl/EfMFDZq/43duyVyQEP1b h/eBXpeYwQJ7s/oGiWcBQfOfaH7XIw5fTqT3s= Received: by 10.227.153.201 with SMTP id l9mr9329545wbw.56.1276731060224; Wed, 16 Jun 2010 16:31:00 -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 u36sm58846340wbv.0.2010.06.16.16.30.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 16 Jun 2010 16:30:59 -0700 (PDT) Message-ID: <4C195EC1.5030709@gmail.com> Date: Thu, 17 Jun 2010 01:31:13 +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: <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> <4C17EB9E.9050309@gmail.com> <20100616130058.GB21862@riva.ucam.org> In-Reply-To: <20100616130058.GB21862@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: Wed, 16 Jun 2010 23:31:04 -0000 Hi, I made several tests, and the patch works fine with standard boot. When multibooting core.img, the command-line is taken into account correctly. However, if no multiboot command-line is given, the prefix is set as before (old partition naming style). This comes from the fact that the modifications to the prefix done in grub-setup only apply to the embedded image, and not to the core.img file. The grub-mkimage command used by grub-install is: grub-mkimage -O i386-pc --output=/path/to/core.img --prefix=/boot/grub Would it make sense to put the full prefix here? >> - 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). > > My investigations suggest that this is very difficult. Relocating the > GRUB kernel, which is almost the first thing multiboot_entry does, is > liable to overwrite the MBI, and you can't get at C code until you've > done that. That's why multiboot_entry has to copy out the boot device > field even before it relocates the kernel. What I meant is: the assembly part could be restricted to the copy of the relevant MBI information, i.e. flags, boot_device and cmdline. And leave the actual decisions regarding the contents of those fields to grub_machine_init(). This would mean that the part dealing with grub_install_dos/bsd_part (multiboot_trampoline) would be part of the C code (probably in make_install_device()). > grub_machine_set_prefix (void) > { > /* Initialize the prefix. */ > - grub_env_set ("prefix", make_install_device ()); > + if (!found_multiboot_prefix) > + grub_env_set ("prefix", make_install_device ()); You could avoid the variable found_multiboot_prefix and use grub_env_find("prefix"). The intention would be that if someone (multiboot or someone else) has already set the prefix in grub_env, then we shouldn't override this choice here. This would simplify a bit grub_parse_multiboot_cmdline(), which would become purely generic. But this is essentially cosmetic... === modified file 'kern/i386/pc/startup.S' > --- kern/i386/pc/startup.S 2010-04-05 13:59:32 +0000 > +++ kern/i386/pc/startup.S 2010-06-16 12:55:05 +0000 > @@ -145,6 +145,32 @@ multiboot_entry: > /* obtain the boot device */ > movl 12(%ebx), %edx The boot_device field should be used only if the MULTIBOOT_INFO_BOOTDEV flag is set. This problem is already present in trunk. > + /* if so, copy it to a safe place; do this before relocating code to > + make sure that we don't lose it */ > + movl 16(%ebx), %edi > + pushl %edi Is it safe to push? Maybe we should start by setting %esp as is done a few lines below. I honestly do not understand all the details regarding the assembly code or the memory management, so I can't provide useful feedback on that. I just noticed that GRUB_MEMORY_MACHINE_MULTIBOOT_FLAGS is copied into a ``regular'' variable, but GRUB_MEMORY_MACHINE_MULTIBOOT_CMDLINE is not. Grégoire