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

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

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

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