qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [RFC] FDT as a git submodule?


From: Anthony Liguori
Subject: Re: [Qemu-devel] [RFC] FDT as a git submodule?
Date: Sun, 27 Jan 2013 08:34:01 -0600
User-agent: Notmuch/0.13.2+93~ged93d79 (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu)

Alexander Graf <address@hidden> writes:

> Am 26.01.2013 um 19:13 schrieb Peter Crosthwaite <address@hidden>:
>
>> Hi All,
>> 
>> On Sat, Jan 26, 2013 at 2:49 AM, Peter Maydell <address@hidden> wrote:
>>> On 26 January 2013 10:11, Andreas Färber <address@hidden> wrote:
>>>> You forget that a "distro" is pretty much a Linux concept. There is no
>>>> such thing on W32 (openSUSE doesn't package it for MinGW either), and on
>>>> Darwin the various competing ports systems suck IMO.
>>>> 
>>>> On OpenBSD there's a "dtc" port but we'd need to assure it's installed
>>>> on the build bots before we mandate it, same for the Linux build bots.
>>> 
>>> Even on Linux having a libfdt that's available to compile against
>>> is a comparatively recent thing -- it was only early 2012 IIRC that
>>> Debian/Ubuntu got this, for instance.
>>> 
>>>> I'm not objecting to mandating it but would like to propose to only
>>>> mandate it for the targets that need it. I.e., if no libfdt available,
>>>> don't install microblaze and ppc softmmu targets. That would still allow
>>>> the average user to emulate x86 or arm without hassles, and it should
>>>> not be needed for linux-user.
>> 
>> Im not proposing to mandate it at all initially. Just setup the
>> configurator such that if you --enable-fdt it gives you an option to
>> submodule it rather than just hard failing at configure time. Its
>> annoying to have to provide instructions for all the different distros
>> for apt/yum or build from source for this component. A "normal" build
>> of QEMU would be unaffected.
>> 
>>> 
>>> I'm leaning towards making FDT compulsory for ARM too: the kernel
>>> is moving strongly in this direction and it is just annoying to
>>> get a qemu that gives up when it encounters an FDT. The only reason
>>> I haven't so far is just that availability in distros/OSes is too
>>> spotty. An in-tree libfdt would solve that.
>>> 
>> 
>> +1. The context of this for us is ARM as well not just out
>> Microblaze/PPC targets. Zynq with no FDT is of limited use and will
>> puke for anyone trying to boot Zynq Linux.
>> 
>>>> The pixman submodule has not been working well for me, it's not a
>>>> universally working solution to be copied either.
>>> 
>>> OTOH libfdt is:
>>> * less than 4000 lines of code, half of which is the public .h file
>>> * specifically intended by upstream to be taken and dropped into
>>>   other peoples' projects (this is how you have to use it if you're
>>>   a bootloader, for instance)
>>> * built by just having your usual make process compile and link
>>>   in an extra seven .c files
>>> 
>>> I don't know if we'd use a git submodule though -- we only want
>>> a single subdir of upstream's git repo, not the whole thing.
>> 
>> I kinda want to take a "better than nothin" philosophy here. If the
>> upstream DTC is broken then you can still fall back to your distros.
>> With the proposal as it stands, your distro FDT will take precedent
>> over the submodule flow anyway. 4000 Lines is a pritty cheap download.
>
> Fair enough.
>
> Anthony, could you please create a mirror of dtc on git.qemu.org so we
> can create a submodule against it.

Done.

http://git.qemu.org/?p=dtc.git;a=tree

Regards,

Anthony Liguori

>
> Alex
>
>> 
>> Regards,
>> Peter
>> 
>>> 
>>> -- PMM
>>> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]