On 03/25/2012 10:45 AM, Avi Kivity wrote:
On 03/25/2012 05:30 PM, Anthony Liguori wrote:
On 03/25/2012 10:18 AM, Avi Kivity wrote:
On 03/25/2012 05:07 PM, Anthony Liguori wrote:
As log as qemu -nodefconfig -cpu westmere -M pc1.1
-nodefconfig is going to eventually mean that -cpu westmere and -M
pc-1.1 will not work.
This is where QEMU is going. There is no reason that a normal user
should ever use -nodefconfig.
I don't think anyone or anything can use it, since it's meaning is not
well defined. "not read any configuration files" where parts of qemu
are continually moved out to configuration files means its a moving
target.
I think you assume that all QEMU users care about forward and
backwards compatibility on the command line about all else.
That's really not true. The libvirt folks have stated repeatedly that
command line backwards compatibility is not critical to them. They
are happy to require that a new version of QEMU requires a new version
of libvirt.
I don't think this came out of happiness, but despair. Seriously,
keeping compatibility is one of the things we work hardest to achieve,
and we can't manage it for our command line?
I hate to burst your bubble, but we struggle and rarely maintain the level of
compatibility you're seeking to have.
I agree with you that we need to do a better job maintaining compatibility which
is why I'm trying to clearly separate the things that we will never break from
the things that will change over time.
-nodefconfig is a moving target. If you want stability, don't use it. If you
just want to prevent the user's /etc/qemu stuff from being loaded, use
-no-user-config.
I'm not saying that backwards compat isn't important--it is. But
there are users who are happy to live on the bleeding edge.
That's fine, but I don't see how -nodefconfig helps them. All it does
is take away the building blocks (definitions) that they can use when
setting up their configuration.
Yes, this is a feature.
Suppose we define the southbridge via a configuration file. Does that
mean we don't load it any more?
Yes. If I want the leanest and meanest version of QEMU that will
start in the smallest number of milliseconds, then being able to tell
QEMU not to load configuration files and create a very specific
machine is a Good Thing. Why exclude users from being able to do this?
So is this the point? Reducing startup time?
Yes, that's one reason. But maybe a user wants to have a whole different set of
machine types and doesn't care to have the ones we provide. Why prevent a user
from doing this?
Maybe they have a management tool that attempts to totally hide QEMU from the
end user and exposes a different set of machine types. It's certainly more
convenient for something like the Android emulator to only have to deal with
QEMU knowing about the 4 types of machines that it specifically supports.
Regards,
Anthony Liguori
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list