Re: [Qemu-devel] [PATCH v2] vl.c: disallow command line fw cfg without opt/

[Michael S. Tsirkin]

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