On Mon, 6 Jan 2014, Peter Maydell wrote: > On 6 January 2014 17:34, Stefano Stabellini > <stefano.stabell...@eu.citrix.com> 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.