From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCcsG-000378-Ju for qemu-devel@nongnu.org; Tue, 16 Dec 2008 11:34:20 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCcsB-00030V-Vc for qemu-devel@nongnu.org; Tue, 16 Dec 2008 11:34:17 -0500 Received: from [199.232.76.173] (port=39514 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCcsB-0002zK-HS for qemu-devel@nongnu.org; Tue, 16 Dec 2008 11:34:15 -0500 Received: from mx20.gnu.org ([199.232.41.8]:23835) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LCcs9-0007AF-H3 for qemu-devel@nongnu.org; Tue, 16 Dec 2008 11:34:13 -0500 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCcs7-0003wM-2J for qemu-devel@nongnu.org; Tue, 16 Dec 2008 11:34:11 -0500 From: Paul Brook Subject: Re: [Qemu-devel] [6064] Implement device tree support needed for Bamboo emulation Date: Tue, 16 Dec 2008 16:34:08 +0000 References: <1229440187.31337.15.camel@localhost.localdomain> <4947D48D.8010203@codemonkey.ws> In-Reply-To: <4947D48D.8010203@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812161634.08950.paul@codesourcery.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Aurelien Jarno On Tuesday 16 December 2008, Anthony Liguori wrote: > Hollis Blanchard wrote: > > If you'd prefer to make libfdt mandatory, I'm fine with that. > > No, it shouldn't be mandatory :-) > > >>> This patch introduces a dependency on libfdt for flat device tree > >>> support. > >> > >> I don't like the way this is done. > >> > >> AFAIK libfdt isn't present in any of the major distros. I thought the > >> conclusion was that we should import libfdt into qemu. > > > > That was our conclusion, but Anthony never agreed. > > Because it's better to let the distros maintain this. That way, they > can deal with security issues, etc. That's fine in theory. In practice it means we can't realistically use libfdt for anything important for at least another 12 months or so. I'm also rather sceptical about the stability of the libfdt API. > > FWIW, I have requested that Fedora and Debian package libfdt, and they > > agreed in principle, but it's still missing in Fedora 10 for example. > > As long as it's heading toward distros, it should be fine. If we decide > to use libfdt for core QEMU functionality (like config file), we should > revisit this though. That's likely to happen fairly soon. And IIUC it's already fairly critical for the new PPC boards. Paul