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: https://www.redhat.com/archives/libvir-list/2020-May/msg00957.html > > > > Reported-by: Laszlo Ersek <ler...@redhat.com> > > Signed-off-by: Michal Privoznik <mpriv...@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 toDo 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.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 ;-)
Thanks, LaszloSure, 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 :|
signature.asc
Description: PGP signature
