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

Re: [libvirt] [Qemu-devel] Modern CPU models cannot be used with libvirt



On 03/25/2012 01:09 PM, Avi Kivity wrote:
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?

How are we preventing a user from doing it?  In what way is -nodefconfig
helping it?

Let me explain it in a different way, perhaps.

We launch smbd in QEMU in order to do file sharing over slirp. One of the historic problems we've had is that we don't assume root privileges, yet want to be able to run smbd without using any of the system configuration files.

You can do this by specify -s with the config file, and then in the config file you can overload the various default paths (like private dir, lock dir, etc.). In some cases, earlier versions of smbd didn't allow you to change private dir.

You should be able to tell a well behaved tool not to read any configuration/data files and explicitly tell it where/how to read them. We cannot exhaustively anticipate every future use case of QEMU.

But beyond the justification for -nodefconfig, the fact is that it exists today, and has a specific semantic. If we want to have a different semantic, we should introduce a new option (-no-user-config).

Regards,

Anthony Liguori

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.

If it supports four types, it should always pass one of them to qemu.
The only thing -nodefconfig adds is breakage when qemu moves something
that one of those four machines relies on to a config file.



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