Re: [PATCH] docs: Discourage users from using fwcfg

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(a)redhat.com&gt; Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com&gt; --- 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**. +