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

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(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(-) >> > > >> >> >> > 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.

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 :|