On Wed, 2011-09-07 at 12:54 -0400, Stefano Stabellini wrote:
> On Wed, 7 Sep 2011, Ian Campbell wrote:
> > On Wed, 2011-09-07 at 10:39 -0400, stefano.stabellini@xxxxxxxxxxxxx
> > wrote:
> > > In order to distinguish between upstream qemu and qemu-xen I am
> > > introducing a new variable named "QEMU" that only if is equal to
> > > "upstream" switches the build system to the new qemu.
> >
> > Thanks Stefano, this integrated support is overdue.
> >
> > Ultimately though I expect we will need a "both" mode since people will
> > want old qemu for compatibility with their existing installed guests and
> > new qemu for new ones. The allegation (and I don't really know how true
> > it is or if it is pessimism or realism) is that some OSes don't cope
> > with having the platform components etc changed under them.
>
> Yes. At that point we'll probably have to always build them both,
Why wait? Why not just do that now.
> including two hvmloader...
Only one hvmloader will be needed, it will include both rombios and
seabios support and it selects the right one at boot time, since the
toolstack pushes down the choice. This is what happens today if you turn
on the SEABIOS option.
> > > Users that want to try the new qemu just have to export QEMU=upstream
> > > before calling make in the xen-unstable top level directory.
> >
> > In xl/libxl we call them "qemu-xen-traditional" and "qemu-xen". Perhaps
> > we should mirror that nomenclature here?
>
> I looked at libxl but I thought that QEMU=qemu-xen would be confusing for
> users/developers.
> Like you said, considering that we already have
> device_model_version=qemu-xen in VM config files, maybe we should go for
> DEVICE_MODEL=qemu-xen?
With the (current) default being DEVICE_MODEL=qemu-xen-traditional? That
would makes sense to me (excepting that, as above, I think we shouldn't
offer it as a choice in the first place).
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
Home