I frankly think it's overengineered, but it's already much better and if it helps converging to a compromise why not.
Alternatives to your proposals follow: On 17/03/2016 14:13, Michael S. Tsirkin wrote: > > QEMU command line: > A. -fw-cfg RFQDN/PATH prepends usr/. So users will not get conflicts > with QEMU hardware Alternative: no need to prepend usr/, I think. > B. -fw-cfg org.qemu/unsupported/XXX as a hack, removes > org.qemu/unsupported/ and leaves just XXX, > for people who want to break^?^?^?^?^?debug QEMU hardware Alternative: fail on: - a blacklist of etc/* files including etc/system-states, etc/smbios/smbios-tables, etc/smbios/smbios-anchor, etc/reserved-memory-end, etc/pvpanic-port, etc/e820, and possibly etc/boot-menu-wait - on all org.qemu/* files - iff etc/boot-menu-wait is blacklisted, fail on org.seabios/boot-menu-wait too. Everything else is passed through. No hacks required. > C. -fw-cfg opt/FOO accepts any path, for backwards compatibility Implicit in my proposed alternative to A. > D. any other use fails Replaced by my alternative to B. RFQDN is just a best practice, and it is not enforced except as proposed in B. For the same reason, no changes are required in the Linux driver. > OVMF: > Can use the compatible opt/ovmf/ for now. [snip] > Long term: Gradually transition OVMF to look up paths in usr/org.uefi/: > if nothing is found there, look up in opt/ovmf/ for backwards > compatibility. Agreed except it would be org.tianocore.edk2.ovmf/ rather than usr/org.uefi. Likewise SeaBIOS would switch from etc/ to an org.seabios/ prefix (for stuff usable from both Coreboot and QEMU, e.g. org.seabios/bootsplash.bmp) or org.qemu/ (for stuff that is specific to QEMU). Files that could be moved from etc/ to org.qemu/ correspond to the ones that are blacklisted in (B), e.g. etc/system-states -> org.qemu/system-states. Paolo
