On 03/16/16 21:31, Michael S. Tsirkin wrote: > On Wed, Mar 16, 2016 at 07:35:09PM +0100, Laszlo Ersek wrote: >> OVMF uses this feature for a few flags. They are all called >> "opt/ovmf/...". I followed the advice in "docs/specs/fw_cfg.txt" (which >> shouldn't be surprising since I seem to have reviewed every patch for >> that file): > > Wait a second. You are saying upsteam OVMF puts files there.
Sorry, I wasn't clear enough. OVMF consumes files that are put there by the user. > If users add their own flags that happen to be in opt/ovmf/ then > what happens? And how do they *know* they should avoid that? > There's no warning, guest just breaks in various ways. > > This is exactly the kind of mess I was worried about. We have a global > namespace with no way to control what goes where. > > opt/ was for end users not firmware. > > The right thing to do would be for ovmf to reserve itself > a directory under root. > > This really needs more thought. For now I'd suggest we drop the whole > interface from 2.6 and come back to it after 2.6. I very strongly disagree. -fw_cfg was invented exactly for the purpose that guest code (mostly, but not exclusively, guest firmware code) can take settings from the user without QEMU's knowledge. We were conscious of the namespace question, which is why the opt/ prefix was strongly recommended for such knobs. Trying to control it all from QEMU (beyond setting aside the opt/ subdirectory, regardless if it's worded "should" or "must"), introducing a central registry for prefixes, would defeat the entire purpose. Subdividing the namespace under opt/ was purposely left open. Then I went with opt/ovmf/ for files that OVMF should take from users because that's the obvious choice. If we want to be extremely paranoid about the namespace, we can modify the recommendation to say "use opt/UUID/...", where UUID is generated with "uuidgen". That's just an example I know from UEFI; it is how the entire namespace question is side-stepped without a central registry. Nonetheless, OVMF is the second of two guest firmwares in total, so "opt/ovmf/" is the obvious choice. Removing the interface would break existing code in OVMF that (a) consumes opt/ovmf/... files and (b) doesn't disturb anything at all otherwise. Plus, the -fw_cfg option was released in 2.4 (added around commit 81b2b81062). Laszlo
