On Thu, Jan 25, 2018 at 05:12:49PM +0100, Andrea Bolognani wrote: > On Thu, 2018-01-25 at 15:03 +0000, Daniel P. Berrangé wrote: > > On Tue, Jan 23, 2018 at 04:45:01PM +0100, Andrea Bolognani wrote: > > > We're going to introduce a number of optional, pSeries-specific > > > features, so we want to have a dedicated sub-element to avoid > > > cluttering the <domain><features> element. > > > > I don't think we want todo this as all. Pretty much *every* single > > existing <feature> element is architecture specific. Adding a nested > > level just for pseries is making it different from existing practice > > and I don't see any benefit to that. > > Well, there's going to be a bunch of them added pretty soon (six > or so) plus probably more down the line, so that's already quite > a bit of clutter. My reasoning was to try and organize them the > way we already do with <kvm> and <hyperv> capabilities - even > though pSeries is not a hypervisor per se, you can kinda see > sPAPR as a specification implemented by various hypervisors, like > PowerVM and in our case QEMU/KVM. But if you think this effort is > misguided and they belong to the top-level <features> element, > then I'm okay with that too. I guess where the nesting makes sense is if there's a chance of having namespace collision between features. eg if both kvm and hyperv had a feature called "pvspinlocks", you might want to enable them separately, so the nesting is important there. If you do think the pSeries nesting is important in this respect, can you still leave the existing "hpt" feature un-nested for sake of full back-compat - just nest new features. 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 :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
