[libvirt] [PATCH] Drop UML driver
Daniel P. Berrangé
berrange at redhat.com
Fri Dec 14 15:05:59 UTC 2018
On Fri, Dec 14, 2018 at 03:59:29PM +0100, Michal Privoznik wrote:
> On 12/14/18 3:53 PM, Daniel P. Berrangé wrote:
> > On Fri, Dec 14, 2018 at 03:46:16PM +0100, Michal Privoznik wrote:
> >> On 12/14/18 3:35 PM, Daniel P. Berrangé wrote:
> >>> On Fri, Dec 14, 2018 at 03:30:17PM +0100, Michal Privoznik wrote:
> >>>> The driver is unmaintained, untested and severely broken for
> >>>> quite some time now. Since nobody even reported any issue with it
> >>>> let us drop it.
> >>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
> >>>> ---
> >>>> docs/schemas/capability.rng | 2 -
> >>>> docs/schemas/domaincommon.rng | 3 -
> >>>> src/conf/domain_conf.c | 11 +-
> >>>> src/conf/domain_conf.h | 4 -
> >>> We shouldn't be deleting stuff from the XML schemas. IMHO the schemas
> >>> are an append only source object. If some parts happen to not be used
> >>> by current code that's fine, but they are a record of the ABI promise
> >>> of the schema.
> >> So we should be able to validate <domain type="uml"/> even though there
> >> is no longer any driver that would define such domain? I don't see much
> >> point in that.
> > The point is that the schema definition is independent of the driver
> > implementations. Implementations in libvirt come & go, but the schema
> > that they adhere to must remain constant.
> >> Also, removing a driver is breaking the ABI promise.
> > To some extent, but I don't consider that equivalent to the promise of
> > stability of our library ELF API or XML schema. Implementations of
> > a feature may have a finite lifetime. The way a feature is described
> > remains the same forever, which is what the XML schema declares. As
> > such its inappropriate to remove something from the schema, just
> > because the feature doesn't exist.
> > This can affect downstream applications, even if they are not actively
> > using the UML driver. For example libraries that provide an API around
> > our XML schema may be validating their implementation against our RNG
> > schemas & thus removing it can break those impls.
> Okay, Fair enough. But what about the domain_conf.c? I think it's safe
> to remove "uml" from there, isn't it? I mean, does it matter whether we
> fail parsing the domain because of unknown domain type or unsupported
> domain type?
IMHO we must keep the code too, because the parser should successfully
parse any document that is compliant with the schema. Whether the driver
later rejects the config as unsupported is a separate matter.
|: 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 :|
More information about the libvir-list