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

[Paolo Bonzini <pbonzini@redhat.com>]

On 17/03/2016 14:49, Michael S. Tsirkin wrote:
>> 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.

I wouldn't include usr/ at all in the paths.  The RFQDN recommendation
is enough to avoid clashes with etc/ and opt/.

>>> 	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.

The reason for the blacklist is that these are files owned by QEMU but
traditionally under etc/.  The error can be simply "fw_cfg file %s is
provided by QEMU".  If a file is added in the future that is owned by
QEMU, it will be under org.qemu/* so the blacklist will not grow.

>> 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.
> 
> 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.

Does it make more sense if it's just org.qemu, not usr/org.qemu?

Thanks,

Paolo