[PATCH] docs: Discourage users from using fwcfg

[Laszlo Ersek]

On 09/07/20 16:38, 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

Yes, I remember that -- I remember that we discussed this, and also that
you didn't have time for it. Which is entirely justifiable; other stuff
has been (and continues to be) more important.

For reference, here's the launchpad ticket that tracks the RFE for QEMU:

  https://bugs.launchpad.net/qemu/+bug/1826200

Thanks,
Laszlo