On Tue, Aug 13, 2013 at 12:24:51PM +0200, Ján Tomko wrote: > On 08/13/2013 11:54 AM, Daniel P. Berrange wrote: > > On Tue, Aug 13, 2013 at 11:53:42AM +0200, Ján Tomko wrote: > >> On 08/13/2013 10:55 AM, Daniel P. Berrange wrote: > >>> On Tue, Aug 13, 2013 at 10:51:04AM +0200, Ján Tomko wrote: > >>>> <controller type='pci' index='0' model='pci-root' pcihole64='1'/> > >>>> > >>>> It can be used to adjust (or disable) the size of the 64-bit > >>>> PCI hole. The size attribute is in gigabytes, since it would > >>>> get rounded up to nearest GB by QEMU anyway. > >>> > >>> Choosing the units based on what one specific hypervisor happens to > >>> currently do has proven to be a pretty bad idea in the past. I'd say > >>> we should be using KB here. Or better yet, have this as a separate > >>> child element, and then support a 'units' attribute at the same time, > >>> defaulting to KB. > >>> > >> > >> Would it be okay to use the largest usable unit when formatting the XML > >> to make it more human-friendly? > > > > No, because you'd be throwing away data if the user had requested less > > than a GB. Outputting XML should use the smallest unit for which we > > want to support, which IMHO should be KB. > > > > By 'usable' I meant the unit that is the largest divisor of the size, e.g.: > 512 KB would stay 512 KB, but 2048 MB would get translated to 2 GB. Ewww, no. The output unit should always be the same for any given attribute. > But this requires the applications parsing the XML to read both the size and > the units. Yep, this exactly why this is a bad idea Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list