[PATCH] docs: Discourage users from using fwcfg

[Martin Kletzander]

On Tue, Sep 08, 2020 at 10:22:34AM +0200, Laszlo Ersek wrote:
>On 09/08/20 08:37, Martin Kletzander wrote:
>> On Mon, Sep 07, 2020 at 03:38:23PM +0100, Daniel P. Berrangé wrote:
>>> On Mon, Sep 07, 2020 at 04:20:02PM +0200, Michal Privoznik wrote:
>>>> On 9/7/20 3:57 PM, Martin Kletzander wrote:
>>>> > On Mon, Sep 07, 2020 at 03:48:16PM +0200, Michal Privoznik wrote:
>>>> > > Even though this was brought up in upstream discussion [1] it
>>>> > > missed my patches: users should prefer <oemStrings/> over fwcfg.
>>>> > > The reason is that fwcfg is considered somewhat internal to QEMU
>>>> > > and it has limited number of slots and neither of these applies
>>>> > > to <oemStrings/>.
>>>> > >
>>>> > > While I'm at it, I'm fixing the example too (because it contains
>>>> > > incorrect element name) and clarifying sysfs/ exposure.
>>>> > >
>>>> > > 1:
>>>> https://www.redhat.com/archives/libvir-list/2020-May/msg00957.html
>>>> > >
>>>> > > Reported-by: Laszlo Ersek <lersek at redhat.com>
>>>> > > Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>>> > > ---
>>>> > > docs/formatdomain.rst | 14 +++++++++-----
>>>> > > 1 file changed, 9 insertions(+), 5 deletions(-)
>>>> > >
>>>>
>>>>
>>>> > It's nice that you say that, but people who would like to use
>>>> fw_cfg for
>>>> > passing
>>>> > in a huge blob, which is saved in a file, will read this, go to
>>>> > <oemStrings/>
>>>> > and see that there is no way to pass a file as an input.  Should
>>>> that be
>>>> > dealt
>>>> > with somehow?  Or would that be discouraged as well?
>>>>
>>>> Unfortunately, QEMU doesn't allow reading OEM strings from a file (at
>>>> least
>>>> quick glance over hw/smbios/smbios.c doesn't show any signs it's
>>>> allowed).
>>>
>>> Indeed, that is an RFE I've never got around to
>>>
>>
>> Do you mean RFE for QEMU or libvirt?
>>
>> Are there any limitations for the oemStrings?  Libvirt could read the
>> file and
>> pass the data to QEMU as it is not something that is supposed to be
>> writeable or
>> shareable.  I understand it could be the first time we do something like
>> this,
>> but it might not be that bad of a precedence.
>>
>> Just so we are on the same page, I'm not against this patch, I just want
>> to save
>> our users the frustration that I, myself, experienced so many times. 
>> There's
>> something deep hurting when you finally find exactly what you're looking
>> for,
>> only to learn that it is deprecated with another option which does not
>> provide
>> the same functionality.
>
>This description is not entirely accurate. I would put it like this: you
>stumble upon a mis-use of a feature that was originally meant for
>something else. It seems that the original consumers of the feature have
>always been unhappy about the mis-use (it presents a risk for the
>subsystem they are responsible for), in spite of the mis-use possibly
>scratching your itch too.
>

That is *also* true, it's just a view from the other perspective.

>That shouldn't hurt your feelings -- the point is that it's not
>"deprecation"; the original thing has never been condoned for this
>particular creative kind of abuse. Instead, the feature that could
>scratch your itch has never existed.
>

This works for empathic readers only ;-)

>Thanks,
>Laszlo
>
>
>> Sure, you can have a start hook that reads a
>> file and
>> changes the data, etc.  But you get the point.  At least we could
>> mention that?
>>
>>> Regards,
>>> Daniel
>>> -- 
>>> |: https://berrange.com      -o-   
>>> https://www.flickr.com/photos/dberrange :|
>>> |: https://libvirt.org         -o-           
>>> https://fstop138.berrange.com :|
>>> |: https://entangle-photo.org    -o-   
>>> https://www.instagram.com/dberrange :|
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20200908/4af17de4/attachment-0001.sig>