Re: [Qemu-devel] [PATCH V4 4/4] fw_cfg: insert fw_cfg file blobs via qemu cmdline

[Laszlo Ersek]

On 06/01/15 12:42, Michael S. Tsirkin wrote:
> On Mon, Jun 01, 2015 at 12:35:34PM +0200, Laszlo Ersek wrote:
>> On 06/01/15 12:23, Michael S. Tsirkin wrote:
>>> On Mon, Jun 01, 2015 at 11:01:23AM +0200, Paolo Bonzini wrote:
>>>>
>>>>
>>>> On 01/06/2015 09:28, Michael S. Tsirkin wrote:
>>>>>> I don't feel overly strongly about it; just "mechanism, not policy"
>>>>>> looks like a good tradition (well, good excuse anyway).
>>>>>
>>>>> Most users never see warnings. We ship it, we support it.
>>>>> If we don't want to support it, let's not ship it.
>>>>
>>>> Then we should rm -rf half of QEMU. :)
>>>>
>>>> Seriously, I agree wholeheartedly with not baking policy into QEMU.  A
>>>> lot of QEMU command-line hacking really is just a shortcut to avoid
>>>> continuous recompilation.  I don't think it's reasonable to expect that
>>>> it constitutes a stable API.
>>>>
>>>> Paolo
>>>
>>> Still, reserving part of the namespace for QEMU internal use
>>> is *not* policy, it's just good engineering.
>>>
>>> How about we forbid adding files under "etc/" ?
>>>
>>> That would be enough to avoid conflicts.
>>
>> Some of the current fw_cfg files, like "bootorder", are not under
>> "etc/".
> 
> Well bootorder is there so at least it will always fail.
> We do have stuff under /rom.
> 
>> Hence the earlier proposal to restrict the user (to under opt/,
>> IIRC), rather than ourselves.
>>
>> Thanks
>> Laszlo
> 
> How about we pre-pend opt/ to user-supplied names?
> Will fix this without limiting user in any way.

(Sorry if this has been addressed in further messages down-thread; I'm
not that far yet.) The issues here are that a user implementing custom
firmware or OS-level code will have to:
(a) take this prefix in account when writing the client code,
(b) blob names have a max length of 55 chars IIRC (+ terminating NUL),
any fixed prefix would decrease that. Not necessarily a problem, but
something to be aware of, at least in the QEMU option parsing.

Thanks
Laszlo