On Mon, Jun 15, 2009 at 09:20:00AM -0500, Anthony Liguori wrote: > 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. And then pc-virtio-class-other-with-balloon-without-usb? Wouldn't it be more straightforward to have capability bits which can be switched on and off independently rather than trying to fit unrelated features into a machine type? IMO it only seems more work at first, and QA gets a bit nervious that they can't exhaustively test all options. But in the long run it simplifies things as you don't have to set policy and invent silly names. > 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 _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/virtualization
