qemu-devel
[Top][All Lists]
Advanced

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

Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] Re: [PATCH 0/9] Virtio cleanups
Date: Tue, 23 Mar 2010 13:58:36 +0200
User-agent: Mutt/1.5.19 (2009-01-05)

On Tue, Mar 23, 2010 at 11:40:46AM +0000, Paul Brook wrote:
> > > Right.  The only real challenge is dealing with legacy save/restore and
> > > command line syntax.  For save/restore, we can possibly have a dummy
> > > device that can split the VirtioPCI device state from the virtio device
> > > states and do the right thing.
> > >
> > > I'm not sure what we should do for command line syntax.  We can keep
> > > -drive working as is.  Do we need to support -device based creation?  I
> > > don't think we've really considered what to do in a situation like this.
> > 
> > If we need to change command line because of an implementation
> > change, IMO something is wrong with the design.
> > Users shouldn't care about non-existent virtio bus.
> 
> I don't find this argument convincing. If we need to change the
> internal structure of a machine, then users who manipulate the machine
> configuration are going to have to compensate for this.
> This kind of change is pretty much unavoidable when we get the device
> model wrong.

I am yet to see why the model is wrong. virtio devices
on pci bus and on s390 bus are different virtual hardware
devices. There's no emulated bus.
This is not much different from e100 - it can emulate tens
of device variants - e100 bus?

Anyway, people really want to share implementation and
want to do this by means of a bus, ok, but there is nothing here
that users care about.

And if we let implermentation leak out to command line, we will have
compat problems down the line.

> The best we can realistically do is avoid making these
> changes on a stable branch, and arrange for outdated configs to be
> rejected rather than silently doing the wrong thing.
> 
> Paul

Practically speaking, we are bound to change internal representation in
the future, and breaking scripts, management tools, documentation and
simple user habits with each such change would be very bad.

-- 
MST




reply via email to

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