On Mon, Apr 23, 2018 at 11:10:01 +0200, Andrea Bolognani wrote:
> On Mon, 2018-04-23 at 08:53 +0200, Peter Krempa wrote:
> > > + The optional <code>enabled</code> attribute can be set to
> > > + <code>no</code> to disable PCI ROM loading completely for the device.
> > > + <span class="since">Since 4.3.0 (QEMU and KVM only)</span>.
> >
> > Maybe you should mention that any other configration may not be
> > supported in that case.
>
> Good idea.
>
> > > @@ -6798,6 +6813,14 @@ virDomainDeviceInfoParseXML(virDomainXMLOptionPtr xmlopt ATTRIBUTE_UNUSED,
> > > goto cleanup;
> > > }
> > > info->romfile = virXMLPropString(rom, "file");
> > > +
> > > + if (info->romenabled == VIR_TRISTATE_BOOL_NO &&
> > > + (info->rombar != VIR_TRISTATE_SWITCH_ABSENT || info->romfile)) {
> >
> > I'd explicitly allow empty string in info->romfile, but that would mean
> > that this needs to be moved to the qemu post-parse callback, since that
> > is a qemu quirk.
> >
> > Justification is that, mgmt tools will be able to use enabled='no'
> > together with the empty file string without having to do any probing
> > whether that is a valid configuration.
>
> But enabled='no' would be rejected by earlier libvirt releases,
> which makes the point about avoiding feature detection moot, no?
No. Only if they enable schema validation. Since that is an opt-in you
still can define such XML and the option will be ignored.
> I would expect management applications that already use (invalid,
> according to the schema, but working fine by all other counts)
> file='' to keep using that until they bump their required libvirt
> version to 4.3.0, and management applications that didn't already
> use the existing kludge to just go straight for enabled='no'.
I guess that is fair enough.
ACK then.
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
