From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LqzxR-0000AC-F1 for mharc-grub-devel@gnu.org; Mon, 06 Apr 2009 21:18:33 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LqzxP-0000A6-8h for grub-devel@gnu.org; Mon, 06 Apr 2009 21:18:31 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LqzxN-00009u-OR for grub-devel@gnu.org; Mon, 06 Apr 2009 21:18:30 -0400 Received: from [199.232.76.173] (port=55856 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LqzxN-00009r-JT for grub-devel@gnu.org; Mon, 06 Apr 2009 21:18:29 -0400 Received: from fg-out-1718.google.com ([72.14.220.154]:13010) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LqzxN-0004du-3c for grub-devel@gnu.org; Mon, 06 Apr 2009 21:18:29 -0400 Received: by fg-out-1718.google.com with SMTP id 19so837716fgg.7 for ; Mon, 06 Apr 2009 18:18:28 -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=w+poPwvk6HDLXaKb8i3YLpFbWG2+KjCgo0aWW4cf2tM=; b=WCGU1rqc20v1Yw5LmxXqT8CX7Eu5fGZuI0SzN9z0HdqZ7/RH9u/V+Xqg9OPH3a6kTW eS448S54X3Sut4dgXut+uBt4+K10U2DYGLT2b67hPvHWsT3UU3QcRnKb+80SX72eWKOQ 9mp164KWqNeKddPuvyPu5d4iGyIN+cueoqr3g= 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=SyiNm6xpZHWHSSWxyhtkDPj62c/2sS/QqWVMsl577EgFZewSz6AcZEC3Yas0FxlSBN f00fOiNKmIR5SIhYLtOp8EpmYd/qfdVT3RvOJkm3vw6w8ROgpoXDxBZcxLgAs9wjaKRD VD0BSW5Jcad5EXmlUQ1F8Cb/MPdpp/1LYMOyE= Received: by 10.86.86.2 with SMTP id j2mr3213859fgb.74.1239067108214; Mon, 06 Apr 2009 18:18:28 -0700 (PDT) Received: from ?192.168.1.2? (153-81.3-85.cust.bluewin.ch [85.3.81.153]) by mx.google.com with ESMTPS id e20sm81009fga.24.2009.04.06.18.18.27 (version=SSLv3 cipher=RC4-MD5); Mon, 06 Apr 2009 18:18:27 -0700 (PDT) Message-ID: <49DAA9E6.2020909@gmail.com> Date: Tue, 07 Apr 2009 03:18:30 +0200 From: phcoder User-Agent: Thunderbird 2.0.0.21 (X11/20090318) MIME-Version: 1.0 To: The development of GRUB 2 References: <49AD5B12.8090904@gmail.com> <49D93FFF.6070601@gmail.com> <200904070924.44083.okuji@enbug.org> In-Reply-To: <200904070924.44083.okuji@enbug.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: multiboot2 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: Tue, 07 Apr 2009 01:18:31 -0000 Yoshinori K. Okuji wrote: >>> 1) double the size of flags. 8 features per category seems to be few. > > I do not agree on this. As you can see, most bits are still undefined after > over 10-year usage of the Multiboot Specification. I do not want to change it > without any real issue. > The difference is that multiboot2 is meant to be portable >>> 3) "The physical address to which the boot loader should jump in order >>> to start running the operating system." >>> In current terminology should make no real sense here > > This is not an italic "should". Just a natural use of English wording. Ok > >>> 4) "This tag should contain a string that enables operating systems to >>> distinguish between different bootloaders and different versions of the >>> same bootloader." >>> Parsing strings may be difficult. Perhaps we could include a version tag >>> with a format dependent on bootloader and optionally a requirement that >>> higher numbers are newer versions? > > I do not think so. The purpose of this tag is for human reading only. For > example, you might want to examine what boot loader booted up your operating > system. So, as long as it is readable for human, that's okay. IMO, operating > systems must not change behaviors based on this tag. > Ok >>> 5)memory map: "The order of memory maps is not guaranteed but a boot >>> loader should sort the items based on the starting addresses. " >>> I don't like the optionality of this rule if it's included in >>> specifications it should be either required or dropped altogether. >>> Otherwise we risk to have OSes which rely on sorting and bootloaders >>> which doesn't sort. I'm personally for making it mandatory for reasons >>> similar to next entry > > There's a good reason to make it optional. If you see GRUB only, you will > think that this behavior should be always implemented, but some boot loaders > are more nervous about the code size, so they want to skip as many features > as they can. In fact, AFAIK, Etherboot didn't implement sorting in its > Multiboot support. > What I want is to avoid is the bitrot as with multiboot1 when due to different issues some kernels boot only with some booters. Such a situation defeats the purpose of the standard >>> 6) memory map. " Tags of this type should be omitted on architectures >>> where the OS is able to retrieve this information from firmware. (Doing >>> do will encourage OS portability across bootloaders, and simplify GRUB >>> development and maintenance.) " >>> This contradicts the goal of easier OS developement and may result in >>> semi-compatible OS and bootloaders. Additionally I think that >>> eliminating the necessity of use of firmware from OS is a good thing and >>> allows easier porting between architectures differing only by firmware > > It is hard for me to say which is better. > > In reality, every OS needs to interact with underlying firmware more or less > to be functional (power control, interrupt handling, etc.). So giving a > memory map does not eliminate the necessity of interactions with firmware > anyway. > This isn't entirely true. Most of OS use their own firmware-independent drivers for most devices. If it doesn't recognize the firmware perhaps some functionality will be disabled but at least OS will be able to boot. This isn't the case with a lot of current OSes specifically targetting one or another firmware but I hope it will vhange in the future because of advent of alternative firmwares. Furthermore different firmwares may implement the same interfaces. A major example is EFI, coreboot and BIOS implementing ACPI. If we add a tag pointing to RSDP then the kernel won't need to know whether it's on EFI, BIOS or coreboot. >>> 7) Command line tag. I propose to reserve the identifier 0x0005 for >>> command line and make it the same format as "Boot Loader Name" but >>> arguments shouldn't include kernel image name. This way we would prevent >>> OSes from trying to access this file by bootloader-specific name. In >>> addition in both "Boot Loader Name" and "Command-line" we should specify >>> the encoding to be utf-8 > > Seemingly, someone made a bad change on the draft, so the information is lost: > > http://grub.enbug.org/MultibootDraft?action=diff&rev2=23&rev1=22 > > Hollis's idea was to use the same format as for modules to give information > about an OS image. A part of this change must be reverted. It is wrong to > adopt the spec to the implementation. > It's ok with me. Quick look through the code suggests that probably kernel tag is created with type MODULE and that it also has an additional field type. I will check it tomorrow but it looks like a bug somewhere And what about encoding? > BTW, I agree that the command line should not include a filename. > > Regards, > Okuji > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko