On Tue, Nov 20, 2018 at 12:11 PM Daniel P. Berrangé <berrange@xxxxxxxxxx> wrote: > > On Thu, Nov 15, 2018 at 12:04:33PM +0100, 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> > > In general our documentation for the osinfo schema is poor to > non-existant. If we start adding features like this, however, > I think it is important that we explicitly document what each > one means as clearly as possible. > > eg 'device-hotplug' presumably refers to PCI device hotplug, > but we should be clear it just means the OS is capable of > supporting it. It doesn't mean its actually guaranteed to > work. eg if either QEMU or kernel is booted with "noapci" > it won't work. > > I'd be ok with the documentation simply comprising XML comments > in the RNG schema There's one thing (from Martin's series*) that makes me wonder whether we should also have something else than just a <feature>foo</feature> attribute. His example is: + <features> + <hugepages size="1" unit="G"/> + <nic>passthrough</nic> + <io>native</io> + <disk cache="none"/> + </features> At this point In wonder two things: - What he's trying to achieve could also take advantage of my proposal? - Shall we follow his suggested syntax? I totally can see my proposal having, for instance: <features> <feature>hugepages</feature> <feature>nic-passthrough</feature> <features> But then, specifying the size of hugepage, for instance, is not something that I was planning to contemplate with my series. Neither I'm convinced that I should. So, the main question here is ... shall I go-ahead with my approach and later on we can come up with a better naming for Martin's proposal or shall we have an agreement about this (and maybe expanding my proposal) right now? *: https://www.redhat.com/archives/libosinfo/2018-November/msg00202.html Best Regards, -- Fabiano Fidêncio _______________________________________________ Libosinfo mailing list Libosinfo@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libosinfo