qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms


From: Anthony Liguori
Subject: Re: [Qemu-devel] Re: [PATCH 3/4] Update makefile to build roms
Date: Sun, 17 May 2009 18:28:31 -0500
User-agent: Thunderbird 2.0.0.21 (X11/20090320)

Paul Brook wrote:
We build the roms in a sub directory of the target build directory.
This is
anticipating a single source base (like uboot) that gets built
differently for
multiple target architectures (PPC, SH4, etc.).

I'm pretty sure this is going to be wrong. i386 and x86-64 use the same rom, and uboot will most likely need to be built for every *bard*

I guess the alternative is to have top-level rules for building roms and then have each target depend on whatever roms it needs. This may include multiple versions of the same rom.

gplbios and vgabios are simple to build so it's where I started.

This worries me. You've probably picked the easiest examples, and already it doesn't fit nicely.

Why are you trying so hard to integrate these into qemu? IMHO they really don't belong there. AFAICS the roms share no significant code with qemu, and require a completely different environment to build. Especially in cross environments I'd expect combining the two to cause much more pain than it's worth. When developing/building roms a native environment is the exception rather than the norm. Even then it's not really a native build, it's more a collection of hacks that allow you get away with using a native toolchain.

For any packager, it's absolutely necessary to build all of the distributed binaries from source.

In general, QEMU does not support anything but lock-step versioning with it's ROMs. There is no ABI between QEMU and the BIOS.

Having multiple packages therefore makes little sense because they can never be independent of each other.

As long as we include binaries in our source tree, I think we ought to also include the source for those binaries.

Regards,

Anthony Liguori




reply via email to

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