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.