Re: [Xen-devel] [Qemu-devel] Project idea: make QEMU more flexible

[Peter Maydell <peter.maydell@xxxxxxxxxx>]

On 6 January 2014 17:34, Stefano Stabellini
<stefano.stabellini@xxxxxxxxxxxxx> wrote:
> On Mon, 6 Jan 2014, Peter Maydell wrote:
>> However I don't think we can have a qemu-system-null
>> (regardless of use cases) until/unless we get rid of
>> all the things which are compile-time decided by
>> the system config. In an ideal world we wouldn't have
>> any of those (and perhaps you could even build
>> support for more than one kind of CPU into one QEMU
>> binary), but as it is we do have them, and so a
>> qemu-system-null is not possible.
>
> What are these compile-time things you are referring to?

The identifiers poisoned by include/qemu/poison.h are
an initial but not complete list. Host and target
endianness is a particularly obvious one, as is the
size of a target long. You may not use these things
in your Xen devices, but "qemu-system-null" implies
more than "weird special purpose thing which only
has Xen devices in it".

Speaking of odd Xen special cases, it's pretty ugly
that builds with Xen enabled override the size of
ram_addr_t... maybe we should get rid of that special
casing one way or the other.

thanks
-- PMM

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel