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

[Stefano Stabellini <stefano.stabellini@xxxxxxxxxxxxx>]

On Mon, 6 Jan 2014, Peter Maydell wrote:
> 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".

I see your point.
Could we allow target endinness and long size being selected at
configure time for target-null?
The default could be the same as the host, or could even be simply
statically determined, maybe little endian, 4 bytes.

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