[PATCH] docs: Discourage users from using fwcfg

[Martin Kletzander]

On Tue, Sep 08, 2020 at 08:03:46AM +0100, Daniel P. Berrangé wrote:
>On Tue, Sep 08, 2020 at 08:37:03AM +0200, 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?
>
>Both.
>
>> 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.
>
>The problem is the size of the command line you end up with.

Good point.

>You need to have QEMU support for reading from the file.
>

Or from an FD, ideally.

>> 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.  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/9a55aa54/attachment-0001.sig>