On 06/01/15 12:43, Paolo Bonzini wrote: > > > On 01/06/2015 12:23, Michael S. Tsirkin wrote: >> Still, reserving part of the namespace for QEMU internal use >> is *not* policy, it's just good engineering. >> >> How about we forbid adding files under "etc/" ? >> >> That would be enough to avoid conflicts. > > I do not understand. What we're doing is free-beer. We can always say > no. What's your worry? > > One usecase of this feature is to avoid recompiling QEMU while playing > with firmware. If you cannot mimic QEMU's behavior (which is to add > "etc/" files), the feature is pointless, or at least I totally cannot > understand its purpose and I'm against merging it.
As far as I understand, the goal is indeed to expose fw_cfg to the host user, without having to recompile QEMU. This would allow site-specific fw_cfg files, for site-specific guest features. Gabriel wanted to control some guest-agent like functionality (on windows too) with it, IIRC. Matt Fleming @Intel might use it for custom OVMF development. I think those are valid goals and should be possible to support even if we isolate QEMU's own fw_cfg namespace strictly from the user (opt/) namespace. This feature is not there to mess with QEMU's "own" fw_cfg files; for those the existent command line switches should be used. Thanks Laszlo
