From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LsiND-000865-MU for mharc-grub-devel@gnu.org; Sat, 11 Apr 2009 14:56:15 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LsiNB-00085M-Vh for grub-devel@gnu.org; Sat, 11 Apr 2009 14:56:14 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LsiNB-00084y-7F for grub-devel@gnu.org; Sat, 11 Apr 2009 14:56:13 -0400 Received: from [199.232.76.173] (port=38578 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LsiNA-00084o-W9 for grub-devel@gnu.org; Sat, 11 Apr 2009 14:56:13 -0400 Received: from fg-out-1718.google.com ([72.14.220.157]:36635) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LsiNA-0002n8-D2 for grub-devel@gnu.org; Sat, 11 Apr 2009 14:56:12 -0400 Received: by fg-out-1718.google.com with SMTP id 19so456469fgg.7 for ; Sat, 11 Apr 2009 11:56:11 -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=5pGBlRbq6EuMpluGHX04cOFZR4jHjPyKoSSKpvuL1mw=; b=XFoL9deXkAY8GfoP5hMEGjvpgXSLtKnLMsojm5t0nCcuJ50GCMQh5QZKN284WIX1n6 N/SuCrwQr2Az2bCJMy7C0qAKjaHQqDu8RrVCvhU0eIo28MeEvHD+3jzKvwFOrpQC4P3u /WVPUmm8BzzAnRVMJBd2oEz31eb4PwLaykq4M= 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=qF48guafP07IIRVh+zt7hoeL3zw8ukZjbN8NWky4ZNngASuF32D2MGh18aKWdNbBoL zFd3FgJI6VMh9mlhrKz2CFZHhk6C4VrWzlWjazC6f8JxlYGN2mIgRiyvXk8H78CPvQtp FNdVP1zCkd/oc/d8f0ndJae74jY1eaiuGIh5M= Received: by 10.86.33.10 with SMTP id g10mr3539968fgg.56.1239476171332; Sat, 11 Apr 2009 11:56:11 -0700 (PDT) Received: from ?192.168.1.25? (122-34.1-85.cust.bluewin.ch [85.1.34.122]) by mx.google.com with ESMTPS id d6sm3954203fga.27.2009.04.11.11.56.10 (version=SSLv3 cipher=RC4-MD5); Sat, 11 Apr 2009 11:56:11 -0700 (PDT) Message-ID: <49E0E7CF.3000002@gmail.com> Date: Sat, 11 Apr 2009 20:56:15 +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> <200904070924.44083.okuji@enbug.org> <49DAA9E6.2020909@gmail.com> <200904100825.23968.okuji@enbug.org> In-Reply-To: <200904100825.23968.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: Sat, 11 Apr 2009 18:56:14 -0000 Yoshinori K. Okuji wrote: > 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? On some platforms the number of features may be bigger > Not really. Even with the most strict spec possible, it is always possible to > depend on implementation details which are not part of the spec. So, if an OS > image does boot only with some implementations, it is a fault in the OS > image, and the OS image should be fixed. > I agree but specification should make such things less likely >>>>> 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. > > For device drivers, yes. For other things, not always. For instance, on Alpha, > you need to use the firmware to enter the privileged mode. AFAIK, no other > choice. I don't know about alpha but on i386 cpu kernel needs only 4 things from the bootloader to be totally firmware-independent: memory map, framebuffer info, rsdp and smbios address. So I propose to add tags for 3 last things and make memory map required. This would encourage creation of OS working on all branches of i386 including coreboot I think on many platforms it's possible to pass some number of parameters to make it firmware-independent too > > From my point of view, the conclusion should be based on whether a boot loader > may want to provide a memory map different from what firmware thinks. Badram? Creepy firmwares? >>> 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 > > Hmm. > Implementation in grub2 matches neither version of the draft. >> And what about encoding? > > Fine for me. I updated the multibootdraft > > Regards, > Okuji > > > _______________________________________________ > Grub-devel mailing list > Grub-devel@gnu.org > http://lists.gnu.org/mailman/listinfo/grub-devel -- Regards Vladimir 'phcoder' Serbinenko