On Thu, Mar 17, 2016 at 02:30:34PM +0100, Paolo Bonzini wrote: > I frankly think it's overengineered, but it's already much better and if > it helps converging to a compromise why not.
Thanks, I'll think of your suggestions over the weekend. We might be able to simplify things a bit. > Alternatives to your proposals follow: I wonder what are the advantages of the alternative though? It is certainly more code, the rules for users are more complex to figure out and need more effort for user to 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. I personally dislike telling user "do X". I don't see a reason not to be friendly and do X. The rare case where users do not want X can be easily enabled. > > 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 We can not predict the future. Future firmware will look for files under etc/mst. Users using this firmware with current QEMU will get a nasty surprise where it previously worked. Besides, it is way easier to maintain and understand a simple rule than a blacklist. > - 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 I am not sure about moving things into usr/org.qemu. These are system files, not user-provided ones. But we can argue about future plans down the road. -- MST
