[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

On Tue, Sep 08, 2020 at 10:22:34AM +0200, Laszlo Ersek wrote:
On 09/08/20 08:37, 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:
> >
> > Reported-by: Laszlo Ersek <lersek redhat com>
> > Signed-off-by: Michal Privoznik <mprivozn 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
quick glance over hw/smbios/smbios.c doesn't show any signs it's

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
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. 
something deep hurting when you finally find exactly what you're looking
only to learn that it is deprecated with another option which does not
the same functionality.

This description is not entirely accurate. I would put it like this: you
stumble upon a mis-use of a feature that was originally meant for
something else. It seems that the original consumers of the feature have
always been unhappy about the mis-use (it presents a risk for the
subsystem they are responsible for), in spite of the mis-use possibly
scratching your itch too.

That is *also* true, it's just a view from the other perspective.

That shouldn't hurt your feelings -- the point is that it's not
"deprecation"; the original thing has never been condoned for this
particular creative kind of abuse. Instead, the feature that could
scratch your itch has never existed.

This works for empathic readers only ;-)


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?

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

Attachment: signature.asc
Description: PGP signature

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]