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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list