From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1OCtID-0000av-Gf for mharc-grub-devel@gnu.org; Fri, 14 May 2010 07:43:01 -0400 Received: from [140.186.70.92] (port=44034 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OCsxh-00006P-RL for grub-devel@gnu.org; Fri, 14 May 2010 07:21:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OCsxf-00017n-TA for grub-devel@gnu.org; Fri, 14 May 2010 07:21:49 -0400 Received: from mail-fx0-f41.google.com ([209.85.161.41]:50173) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OCsxf-00017d-Oo for grub-devel@gnu.org; Fri, 14 May 2010 07:21:47 -0400 Received: by fxm20 with SMTP id 20so622503fxm.0 for ; Fri, 14 May 2010 04:21:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:date:from:to:cc:subject :message-id:in-reply-to:references:reply-to:x-mailer:mime-version :content-type:content-transfer-encoding; bh=YmTmCbcSNLwBHQZjf9i/i9ZUx/nfZupuIjmWOsnAERE=; b=x2zDoht3TYOaRF1NXf4WJxPDijh78jfTGRQCs2obXukwSNdxJO+EeDtIFuCU7mGXTn bEwxaRZ+tncqT/ZLF/PK6H9no98B/MHv3FQwatIH3G+8kRyFyaltVOxGvA/IN6A6gOqS Fn5NzDMA9FOs1OilLBC5u9IH58HQWyYyYGp2A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=date:from:to:cc:subject:message-id:in-reply-to:references:reply-to :x-mailer:mime-version:content-type:content-transfer-encoding; b=lvAuph8FYDbaWWzy9es1Qevrd9vrPCGy+TNeFmLeyJTiooWCaQ8yXRf7Yzyd7sZOoD KZZGNz3PSz8FlFZSACD+QAP5ib9dUwa7pBBY57SQ0XrMRpBOJkGVjMCxPk0dMCZ8Vy5p bbMmwtPcAPwLgaGd3G6yj5IdvCjGGJL8YR/x0= Received: by 10.223.99.78 with SMTP id t14mr1419854fan.85.1273836104619; Fri, 14 May 2010 04:21:44 -0700 (PDT) Received: from ernst.jennejohn.org (p57AE4DB2.dip.t-dialin.net [87.174.77.178]) by mx.google.com with ESMTPS id u12sm10495549fah.4.2010.05.14.04.21.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 14 May 2010 04:21:43 -0700 (PDT) Date: Fri, 14 May 2010 13:21:42 +0200 From: Gary Jennejohn To: Vladimir =?UTF-8?Q?'=CF=86-coder/phcoder'?= Serbinenko Message-ID: <20100514132142.252b092d@ernst.jennejohn.org> In-Reply-To: <4BECEE31.3060004@gmail.com> References: <4BE98FB5.3060906@gmail.com> <20100514020055.GB89230@duncan.reilly.home> <4BECEE31.3060004@gmail.com> X-Mailer: Claws Mail 3.7.5 (GTK+ 2.18.7; amd64-portbld-freebsd9.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Mailman-Approved-At: Fri, 14 May 2010 07:43:00 -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: Fri, 14 May 2010 11:21:51 -0000 On Fri, 14 May 2010 08:31:13 +0200 Vladimir '__-coder/phcoder' Serbinenko wrote: > > 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... > > > > > Yes and No. multiboot2 describes some aspects of the host system > hardware but I've never heard of device trees outside of IEEE1275 or > xnu, where it's probably a historical leftover. If this specification is > clear and share some of our goals we can think of collaboration. Our > goals in this direction: > 1) Allow the same kernel load on all machines implementing the same ISA. > This will require supplying info about machine. > 2) Keep the things as advanced as they need to but not more advanced. > E.g. when you supply an info about serial port you tell: it's at I/O > port N rather than: it's in PCI bar X of device Y offset F. Since if OS > doesn't support PCI this info is useless and if it does it will find out > that this address is actually a part of PCI bar. This can be discussed > though. > 3) Firmware independency. Ideally OS shouldn't care at all which > firmware it's running on. In some cases we may add pointers to firmware > interfaces if there are good reasons for it but it's not the goal > > So if it's something clean and nice we should try integrating it. If > it's however yet another firmware-dependant overkill interface it should > be avoided. > As an example of what I think Andrew was addressing, U-Boot can pass a Flattened Device Tree to the Linux kernel. This basically allows a Linux kernel to handle variants of a board without having to custom compile Linux for each board. At the moment I think only powerpc-based boards can be handled in this way. -- Gary Jennejohn