From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Ls3cg-0007Rk-Ny for mharc-grub-devel@gnu.org; Thu, 09 Apr 2009 19:25:30 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ls3ce-0007Qf-OA for grub-devel@gnu.org; Thu, 09 Apr 2009 19:25:28 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ls3cd-0007QL-TS for grub-devel@gnu.org; Thu, 09 Apr 2009 19:25:28 -0400 Received: from [199.232.76.173] (port=44306 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ls3cd-0007QI-Or for grub-devel@gnu.org; Thu, 09 Apr 2009 19:25:27 -0400 Received: from mail.nexedi.com ([91.121.25.85]:44896 helo=nexedi.com) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ls3cd-0005Md-9a for grub-devel@gnu.org; Thu, 09 Apr 2009 19:25:27 -0400 Received: from [10.8.0.46] (unknown [10.8.0.46]) by nexedi.com (Postfix) with ESMTP id 434263EBB6 for ; Fri, 10 Apr 2009 01:25:22 +0200 (CEST) From: "Yoshinori K. Okuji" Organization: enbug.org To: The development of GRUB 2 Date: Fri, 10 Apr 2009 08:25:23 +0900 User-Agent: KMail/1.9.10 References: <49AD5B12.8090904@gmail.com> <200904070924.44083.okuji@enbug.org> <49DAA9E6.2020909@gmail.com> In-Reply-To: <49DAA9E6.2020909@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200904100825.23968.okuji@enbug.org> X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) 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: Thu, 09 Apr 2009 23:25:29 -0000 On Tuesday 07 April 2009 10:18:30 phcoder wrote: > 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 Yes, but so? > > There's a good reason to make it optional. If you see GRUB only, you wi= ll > > 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 Not really. Even with the most strict spec possible, it is always possible = to=20 depend on implementation details which are not part of the spec. So, if an = OS=20 image does boot only with some implementations, it is a fault in the OS=20 image, and the OS image should be fixed. > >>> 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 wi= th > > firmware anyway. > > This isn't entirely true. Most of OS use their own firmware-independent > drivers for most devices. =46or device drivers, yes. For other things, not always. For instance, on A= lpha,=20 you need to use the firmware to enter the privileged mode. AFAIK, no other= =20 choice. =46rom my point of view, the conclusion should be based on whether a boot l= oader=20 may want to provide a memory map different from what firmware thinks. If ye= s,=20 we have a good reason to make it required. If no, not much. > > Seemingly, someone made a bad change on the draft, so the information is > > lost: > > > > http://grub.enbug.org/MultibootDraft?action=3Ddiff&rev2=3D23&rev1=3D22 > > > > 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 Hmm. > And what about encoding? =46ine for me. Regards, Okuji