From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OJtuu-0001qD-2T for mharc-grub-devel@gnu.org; Wed, 02 Jun 2010 15:47:56 -0400 Received: from [140.186.70.92] (port=47804 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OJteD-0006ho-4I for grub-devel@gnu.org; Wed, 02 Jun 2010 15:30:45 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OJte6-0002Bl-6L for grub-devel@gnu.org; Wed, 02 Jun 2010 15:30:41 -0400 Received: from trout.icecube.wisc.edu ([128.104.255.119]:39513 helo=mail.icecube.wisc.edu) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OJte5-0002BS-VH for grub-devel@gnu.org; Wed, 02 Jun 2010 15:30:34 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 801CB582C0; Wed, 2 Jun 2010 14:02:21 -0500 (CDT) X-Virus-Scanned: amavisd-new at icecube.wisc.edu Received: from mail.icecube.wisc.edu ([127.0.0.1]) by localhost (trout.icecube.wisc.edu [127.0.0.1]) (amavisd-new, port 10030) with ESMTP id kWuHyA0ouxeK; Wed, 2 Jun 2010 14:02:21 -0500 (CDT) Received: from wanderer.tachypleus.net (i3-dhcp-172-16-223-145.icecube.wisc.edu [172.16.223.145]) by mail.icecube.wisc.edu (Postfix) with ESMTP id 515BB582BE; Wed, 2 Jun 2010 14:02:21 -0500 (CDT) Message-ID: <4C06AABD.1000004@freebsd.org> Date: Wed, 02 Jun 2010 14:02:21 -0500 From: Nathan Whitehorn User-Agent: Thunderbird 2.0.0.24 (X11/20100504) MIME-Version: 1.0 To: =?UTF-8?B?VmxhZGltaXIgJ8+GLWNvZGVyL3BoY29kZXInIFNlcmJpbmVua28=?= References: <4BE98FB5.3060906@gmail.com> <20100514020055.GB89230@duncan.reilly.home> <4BFAC322.7070905@gmail.com> <4BFAEA79.4020901@gmail.com> In-Reply-To: <4BFAEA79.4020901@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Mailman-Approved-At: Wed, 02 Jun 2010 15:47:53 -0400 Cc: The development of GRUB 2 , Andrew Reilly , freebsd-arch@freebsd.org Subject: Re: [RFC] Multiboot2 drafting 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: Wed, 02 Jun 2010 19:30:46 -0000 Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > Vladimir '=CF=86-coder/phcoder' Serbinenko wrote: > =20 >> Andrew Reilly wrote: >> =20 >> =20 >>> Hi there, >>> >>> I know next to nothing about GRUB, and have not yet read the >>> multiboot spec, but I wonder if you could comment on how or >>> whether this is related to either the Open Firmware Device Tree >>> or the Flattened Device Tree used in various embedded OS ports. >>> It would be cool if there were some convergence going on... >>> >>> =20 >>> =20 >>> =20 >> I've looked into it and found good and bad things. >> Good: >> -represents the info needed to OS. It's something definitely good and >> goes in direction we need >> Bad: >> -it basically has all the history ballast of OpenFirmware. OFW is >> supposed to be system-independent but in fact there is a multitude of >> implementation with various degrees of compatibility. Same goes for >> device trees. The same information is present in different places with >> lots of special cases. Many of fields are actually useless variant sel= ectors >> -it uses string identifiers instead of magic numbers. This makes it mo= re >> difficult to parse >> -the most useful information is coming at the leaves and interpretatio= n >> depends on whole path. >> =20 >> =20 > And traditional OpenFirmware has too much info which is probably > useless. E.g. once you know where PCI controller is and you support PCI > you can probe devices which are on it. If you don't support PCI > controller the info about devices on it is probably useless too. > Only exception is "early" info which is needed to e.g. setup console > before normal drivers are up > =20 This isn't quite true. The FDT standard does not require you to add=20 discoverable devices to the tree, for one, and it actually can be useful=20 to have them in many circumstances, as well. For instance, suppose you=20 have some kind of complicated object on the PCI bus (a GPIO controller,=20 or an I2C bus). The children of the I2C bus need to be enumerated in the=20 tree, since there is no other way to discover them, and it is also=20 necessary to identify the I2C controller with a PCI device. -Nathan