qemu-devel
[Top][All Lists]
Advanced

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

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


From: Stefano Stabellini
Subject: Re: [Qemu-devel] Project idea: make QEMU more flexible
Date: Tue, 7 Jan 2014 13:26:10 +0000
User-agent: Alpine 2.02 (DEB 1266 2009-07-14)

On Mon, 6 Jan 2014, Peter Maydell wrote:
> On 6 January 2014 17:34, Stefano Stabellini
> <address@hidden> 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.



reply via email to

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