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

[Avi Kivity]

On 03/26/2012 09:00 PM, Anthony Liguori wrote:
>>> 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.

100% agree.  But that says nothing about a text file that defines
"westmere" as a set of cpu flags, as long as we allow the user to define
"mywestmere" as a different set.  That is because target-x86_64.cfg does
not configure anything, it just defines a macro, which qemu doesn't
force you to use.

>
> 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).

Sure.

-- 
error compiling committee.c: too many arguments to function