On Thu, Mar 17, 2016 at 02:28:38PM +0100, Laszlo Ersek wrote: > On 03/17/16 11:22, Gerd Hoffmann wrote: > > Hi, > > > >> Occasionally, yes. > >> > >> - "opt/ovmf/PcdPropertiesTableEnable" controls whether the "properties > > > >> - "opt/ovmf/PcdSetNxForStack" controls whether the stack is made > > > >> - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which the > > > >> In downstream, we have two more (same purpose but separately for ARM and > >> x86): > >> - opt/aavmf/PcdResizeXterm > >> - opt/ovmf/PcdResizeXterm > >> > >> - Another flag I might expose later is "PcdHiiOsRuntimeSupport". This > > > > I think we should probably move those out of the opt/ namespace space, > > as this is reserved for user-defined files. > > > > I think either "etc/efi/" > > This is more or less what Paolo suggests. > > It confuses me. > > I have now re-read the last section of "docs/specs/fw_cfg.txt" to make > sure my current mental image of the original idea has not diverged from > the actual original idea. I don't think so. > > So, "user defined files" exist so that users can control "stuff" with > them, without QEMU's knowledge. OVMF is "stuff". Just because it's > firmware, it remains "stuff". Whatever Gabriel wants to control with > such fw_cfg files in the guest, is also "stuff". I don't see any > difference between a user controlling an ad-hoc application of his with > "opt/blah1", and controlling OVMF behavior under "opt/ovmf/xizzy". If > the user tries to control his own app by choosing the name > "opt/ovmf/xizzy", that's *his* fault. "opt/ovmf/" is not a prefix > someone comes up with by chance. > > We meant just two partitions of the namespace. "opt/" and non-"opt/". > The latter belongs to QEMU, the former belongs to everything else, and > the subdivision of everything else doesn't belong into QEMU. OVMF is > part of everything else.
This is where we made a design mistake. There are 3 kinds of users adding entries: QEMU, QEMU firmware developers and QEMU users. And QEMU users could be further subdivided. > If we're paranoid about it, we can make a recommendation that each user > pick "opt/UUID/..." for himself, running "uuidgen" and then sticking > with the output for his own stuff. That will guarantee that no conflicts > will be seen. OVMF could be adapted to that as well. (The only snag with > uuidgen is that it would leave only 56 - 4 - 36 - 1 == 15 characters for > the actual knob name.) > > Choosing "etc/" for such files of OVMF that are passed in with the > -fw_cfg switch would be the textbook example of violating the original > idea, because etc/ is heavily populated by QEMU itself. > > > or "efi/" is useful (so we don't have > > different names on ovmf and aavmf). > > I dislike efi/. It suggests that it controls some features that all UEFI > implementations offer. > > > Possibly add "pcd/". Maybe even > > support setting *any* pcd via "efi/pcd/$name" (just an idea, not sure > > whenever that is useful and is possible without being too invasive). > > It's all of: too invasive, not always useful, and not flexible enough. > Knobs should be exposed (with their different value domains) on a > case-by-case basis. > > >> - "opt/ovmf/X-PciMmio64Mb" controls the size of the range from which > > > > Hmm. Leave as-is for now I'd say. > > Will do. > > > If we decide to keep it we should > > probably rename it and place it below etc/, next to reserved-memory-end. > > Export the size in bytes, like reserved-memory-end does. Add an option > > to qemu to set it, so you can specify the size as "32G" using the > > standard qemu size parser. > > I certainly don't disagree with this, but if it goes under etc/, and -- > hence necessarily -- also gets its own command line option, then SeaBIOS > should probably adhere to it as well (or the QEMU manual should state > that this option is also firmware specific). > > Thanks > Laszlo