On Fri, Nov 16, 2018 at 02:33:03PM -0500, Cole Robinson wrote: > On 11/15/2018 06:04 AM, Fabiano Fidêncio wrote: > > One of the requests that came from KubeVirt is that would be really nice > > if we could expose Guest supported features. > > > > In order to do so, I came up with this *prototype* and I'd like to ask > > for some review of the schema before I actually start implementing > > something on libosinfo side. > > > > One example of how it'll look like is: > > <os> > > <features> > > <feature removed="true">device-hotplug</feature> > > <feature>cpu-hotplug</feature> > > <feature>NUMA</feature> > > </features> > > </os> > > > > > From the start: > > - features *will* be inrited between OSes, by default. > > - the feature element has an optional "removed" attribute which, by > > default, is "false". > > > > Is this approach okay? > > > > ACK, this looks like what I imagined as well. It will work like <devices> > but just advertises unique string values. The main thing for us will be to > thoroughly document the semantics of each string value. > > The term 'feature' is kinda misleading because I can see this functionality > being used to advertise anti-features, like an OS bug that affects guest > config. I listed some cases here[1]. But I can't think of anything better, > and I doubt there's any single term that can cover all possible usages of > this functionality without being meaningless, so I'm cool with 'feature' The 'removed' attribute could be changed to deal with anti features in a saner way, by calling it "supported" as a boolean. <feature supported="yes|no">cpu-hotplug</feature> IOW, an anti-feature is simply a feature with supported=no > [1]: https://www.redhat.com/archives/libosinfo/2018-September/msg00002.html 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 :| _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo
