On 2018.07.27 16:45:55 +0200, Erik Skultety wrote: > On Thu, Jul 26, 2018 at 06:04:10PM +0200, Cornelia Huck wrote: > > On Thu, 26 Jul 2018 17:43:45 +0200 > > Erik Skultety <eskul...@redhat.com> wrote: > > > > > On Thu, Jul 26, 2018 at 05:30:07PM +0200, Cornelia Huck wrote: > > > > One thing I noticed is that we have seem to have an optional (?) > > > > vendor-driver created "aggregation" attribute (which always prints > > > > "true" in the Intel driver). Would it be better or worse for libvirt if > > > > it contained some kind of upper boundary or so? Additionally, would it > > > > > > Can you be more specific? Although, I wouldn't argue against data that > > > conveys > > > some information, since I would treat the mere presence of the optional > > > attribute as a supported feature that we can expose. Therefore, additional > > > *structured* data which sets clear limits to a certain feature is only a > > > plus > > > that we can expose to the users/management layer. > > > > My question is what would be easiest for libvirt: > > > > - "aggregation" attribute only present when driver supports aggregation > > (possibly containing max number of resources to be aggregated) > > - "aggregation" attribute always present; contains '1' if driver does > > not support aggregation and 'm' if driver can aggregate 'm' resources > > Both are fine from libvirt's POV, but IMHO the former makes a bit more sense > and I'm in favour of that one, IOW the presence of an attribute denotes a new > functionality which we can report, if it's missing, the feature is clearly > lacking- I don't think we (libvirt) should be reporting the value 1 explicitly > in the XML if the feature is missing, we can assume 1 as the default. >
Good I'll adhere to that, thanks! -- Open Source Technology Center, Intel ltd. $gpg --keyserver wwwkeys.pgp.net --recv-keys 4D781827
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
