[PATCH] docs: Discourage users from using fwcfg

[Martin Kletzander]

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(-)
>
>diff --git a/docs/formatdomain.rst b/docs/formatdomain.rst
>index 1979dfb8d3..821ffe8d60 100644
>--- a/docs/formatdomain.rst
>+++ b/docs/formatdomain.rst
>@@ -509,18 +509,22 @@ layout of sub-elements, with supported values of:
>    Some hypervisors provide unified way to tweak how firmware configures itself,
>    or may contain tables to be installed for the guest OS, for instance boot
>    order, ACPI, SMBIOS, etc. It even allows users to define their own config
>-   blobs. In case of QEMU, these then appear under domain's sysfs, under
>+   blobs. In case of QEMU, these then appear under domain's sysfs (if the guest
>+   kernel has FW_CFG_SYSFS config option enabled), under
>    ``/sys/firmware/qemu_fw_cfg``. Note, that these values apply regardless the
>    <smbios/> mode under <os/>. :since:`Since 6.5.0`
>
>+   **Please note that because of limited number of data slots use of fwcfg is
>+   strongly discouraged and <oemStrings/> should be used instead**.
>+

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?
-------------- 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/20200907/12cd5b8f/attachment-0001.sig>