Mark McLoughlin wrote:
On Mon, 2009-06-15 at 07:48 -0500, Anthony Liguori wrote:
Eventually the
default configuration becomes increasingly unusable and you need a new
baseline. You must still be able to fall back to the old baseline for
older guests. I don't think games with configuration files can hide
that.
-M pc1
-M pc2
etc.
This is pretty easy to maintain with config files.
I think this would be reasonable, but it is essentially just a version
number which you objected to on the basis that it would make
cherry-picking harder for distros.
It doesn't have to be pc1, pc2. It could be pc-with-usb or
pc-with-balloon. If a distro cherry picks in such a way that their pc
is not a standard QEMU pc, they would add a new PC type that's specific
to their distro.
One thing that would be nice with this '-M pc1' thing would be to retain
'-M pc' as a symlink to the latest version. We'd also need a way to read
the symlink too, so that you can query what the current latest version
is and use that in future.
Another option is an explicit -M default which always uses the default
machine for the architecture. Likewise, we would need a way to query
what the default machine was for an architecture.
How would this machine type version relate to e.g. changing the default
PCI class of virtio-blk? Would we bump the version number of all machine
types can use virtio-blk?
You would introduce a new machine type. For instance,
pc-virtio-class-other. The names don't have to look like that, I'm just
doing that to make a point. This may mean that you end up with dozens
of machine types but you preserve compatibility, which is a good thing.
Of course, the flip side is that you make preserving the machine config
the duty of the user and we don't maintain compatible machine types.
This won't work without a proper config file though so for now, we're
stuck maintaining machine types.
Regards,
Anthony Liguori
--
To unsubscribe from this list: send the line "unsubscribe kvm" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
