From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1NWZSF-0005Ek-DV for mharc-grub-devel@gnu.org; Sun, 17 Jan 2010 13:02:27 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NWZSD-0005ES-Lj for grub-devel@gnu.org; Sun, 17 Jan 2010 13:02:25 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NWZS9-0005B2-CG for grub-devel@gnu.org; Sun, 17 Jan 2010 13:02:25 -0500 Received: from [199.232.76.173] (port=35099 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NWZS9-0005Au-3s for grub-devel@gnu.org; Sun, 17 Jan 2010 13:02:21 -0500 Received: from mail-ew0-f224.google.com ([209.85.219.224]:44708) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1NWZS8-0007On-Go for grub-devel@gnu.org; Sun, 17 Jan 2010 13:02:20 -0500 Received: by ewy24 with SMTP id 24so2703710ewy.26 for ; Sun, 17 Jan 2010 10:02:19 -0800 (PST) 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=UqulOk4AAdLMSxglYimRPKkyBU5lmfr9I2orTdfYMMg=; b=i/3WicoE/S72oO9tBzm/3YHplNn266XzJQWGyDUFMPR59rlmXBdDw3O4ANuQT7T/rG FF8Hv7NOUG3aanAhkQcStnVBCCW1yYkYHbI9E9QZ4zAOI+2o+47bJl4WjvHDVdbBFAzN 7eEZfn4NOOiZgwFEdlDp63W51E+/SUQBmZVYg= 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=eajkYDHPzIw+I7lqNqb/93mCuf9csIqGgQ7m+5MLqRe4YJlL5WnqbWZM/WxWeORo3A ZYUcthbrQAnMy2LAzxv8VibFEF6XXlKcjl7Jlj6b5KZZUvumVeRsasp8SQ78rYllAOBT coIP86miq/OtJ4ACSjJIR4PW8vYzXl0CXrO64= Received: by 10.213.100.131 with SMTP id y3mr5390307ebn.91.1263751338576; Sun, 17 Jan 2010 10:02:18 -0800 (PST) Received: from ?192.168.1.111? (c2433-1-88-160-112-182.fbx.proxad.net [88.160.112.182]) by mx.google.com with ESMTPS id 24sm5110386eyx.46.2010.01.17.10.02.17 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 17 Jan 2010 10:02:18 -0800 (PST) Message-ID: <4B5350A8.5040108@gmail.com> Date: Sun, 17 Jan 2010 19:02:16 +0100 From: =?UTF-8?B?R3LDqWdvaXJlIFN1dHJl?= User-Agent: Thunderbird 2.0.0.23 (X11/20091027) MIME-Version: 1.0 To: The development of GRUB 2 References: <4B4F4C05.8070003@gmail.com> <20100115161507.GA22087@thorin> In-Reply-To: <20100115161507.GA22087@thorin> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: [multiboot] command-line format 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: Sun, 17 Jan 2010 18:02:25 -0000 Hi Robert, Thanks for your detailed explanation, it was really helpful to me. I understand that for compatibility with some platforms, GRUB must provide a way to specify two potentially different file parameters: (a) the GRUB path to the booted file; this path does not appear in the multiboot command-line. (b) the path that shall be passed to the booted file; this path (if any) is the first argument in the multiboot command-line. However, my first post in this thread was more about the multiboot specification itself. In light of your explanations, I would re-phrase my suggestion as follows: in the multiboot specification, require that the first argument of the MB command-line be a path to the booted file *in a notation that is specific to the booted kernel*. Or, if this is too constraining or too confusing, simply ask that the first argument is an informative string that does not contain kernel options (i.e. it can safely be skipped). This way, the specification would be closer to the reference implementation (GRUB Legacy), and, more importantly, to what multiboot-compliant kernels already *assume* about the format of the command-line (NetBSD, OpenSolaris, Xen, others?). For GRUB 2, this could be implemented by a multiboot command that, by default, behaves as GRUB Legacy, but also offers a way to modify the implicit first argument of the multiboot command-line. Something like: multiboot $path[;$ospath] ... (a) $path is the GRUB path to the booted file. (b) $ospath is the path that shall be passed to the booted file. By default, if there is no ';' in the first argument, $ospath is set to the value that GRUB Legacy would have used. Maybe a GRUB shell variable `multiboot_ospath' would be better than this ';' marker. This way, we keep the extra flexibility of having different paths, but we also: - keep backward compatibility with GRUB Legacy: kernels can still assume that the first argument of the multiboot command-line is not a kernel option. - don't force users to repeat the path for kernels that are happy with the way GRUB Legacy worked (all of them except OpenSolaris?). I agree that this point is of no concern to most users, but in some cases grub-mkconfig does not work (e.g. grub-mkconfig does not support --root-directory at the moment), and some users prefer the flexibility of the command line anyway. Grégoire