From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lqbr9-0006HF-F4 for mharc-grub-devel@gnu.org; Sun, 05 Apr 2009 19:34:27 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lqbr7-0006H7-6R for grub-devel@gnu.org; Sun, 05 Apr 2009 19:34:25 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lqbr5-0006Gv-Pg for grub-devel@gnu.org; Sun, 05 Apr 2009 19:34:23 -0400 Received: from [199.232.76.173] (port=42612 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lqbr5-0006Gs-L1 for grub-devel@gnu.org; Sun, 05 Apr 2009 19:34:23 -0400 Received: from fg-out-1718.google.com ([72.14.220.152]:5970) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lqbr5-0003qt-1I for grub-devel@gnu.org; Sun, 05 Apr 2009 19:34:23 -0400 Received: by fg-out-1718.google.com with SMTP id 19so699638fgg.7 for ; Sun, 05 Apr 2009 16:34:22 -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=asMVE1R85T1oGM/5QvXQ0hRC6h0BubzBpU/URhiNrmw=; b=Gi3rbpU3+5JqPUUJfka8SKZIqTSomDmaE+zaL0XDvuEgmzVdnw5cf122/NRHlgOmrv aIs3DVMTl9bxeCznE0gVZ8/rejO1NjRCYFQMNaInjq+EuP5RjEGnGQ/1vLEKcuEXPpp0 pOnRViUvqpty43fDQa/gMbIrWxz7k78Qflkgo= 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=b9TGbeRVC+vO/d2YVtWq/buq/Qn877azF6gyX06S1pkvzXIz2huLRAZHGueLxc+/hB +nsozDYLM5E158+PzsvyqVJYueGT1nTHkNho10uGbk+FQaHHuDw4zu19ZOEN/iS5TE4P iI4rTraKE0bFZpVnEn4pimhyLzflwj+/CsTeo= Received: by 10.86.76.16 with SMTP id y16mr2616013fga.35.1238974462223; Sun, 05 Apr 2009 16:34:22 -0700 (PDT) Received: from ?192.168.1.2? (52-101.3-85.cust.bluewin.ch [85.3.101.52]) by mx.google.com with ESMTPS id 3sm6409513fge.24.2009.04.05.16.34.21 (version=SSLv3 cipher=RC4-MD5); Sun, 05 Apr 2009 16:34:21 -0700 (PDT) Message-ID: <49D93FFF.6070601@gmail.com> Date: Mon, 06 Apr 2009 01:34:23 +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> In-Reply-To: <49AD5B12.8090904@gmail.com> 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: Sun, 05 Apr 2009 23:34:25 -0000 These issues still remain phcoder wrote: > Hello I was looking into multiboot2 specifications and have some > suggestions: > 1) double the size of flags. 8 features per category seems to be few. it > could even be made completely expandable by the following format: > > > > > ... > > 2) "All undefined flags *should* be set to zero for future use. " > IMO in this place all OSes should be required to follow this rule in > current terminology it would be "must" > 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 > 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? > 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 > 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 > 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 > > -- Regards Vladimir 'phcoder' Serbinenko