From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LCdOZ-0000oN-3u for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:07:43 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LCdOX-0000nY-Bj for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:07:42 -0500 Received: from [199.232.76.173] (port=45566 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LCdOX-0000nQ-3a for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:07:41 -0500 Received: from mail-bw0-f12.google.com ([209.85.218.12]:54081) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LCdOW-00089p-7p for qemu-devel@nongnu.org; Tue, 16 Dec 2008 12:07:40 -0500 Received: by bwz5 with SMTP id 5so6031141bwz.10 for ; Tue, 16 Dec 2008 09:07:35 -0800 (PST) Message-ID: Date: Tue, 16 Dec 2008 19:03:39 +0200 From: "Blue Swirl" Subject: Re: [Qemu-devel] [6064] Implement device tree support needed for Bamboo emulation In-Reply-To: <200812161634.08950.paul@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1229440187.31337.15.camel@localhost.localdomain> <4947D48D.8010203@codemonkey.ws> <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: qemu-devel@nongnu.org Cc: Aurelien Jarno On 12/16/08, Paul Brook wrote: > 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. I also vote for importing libfdt for now, it should be useful for Sparc too. If one day the major distros (think also about BSDs, Solaris etc.) have libfdt, we can remove ours.