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: Alexander Graf
Subject: Re: [Qemu-devel] [RFC] FDT as a git submodule?
Date: Sat, 26 Jan 2013 19:27:39 +0100


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.

Alex

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



reply via email to

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