On Wed, Oct 31, 2007 at 05:43:47PM +0000, Daniel P. Berrange wrote: > On Wed, Oct 31, 2007 at 01:36:48PM -0400, Daniel Veillard wrote: > > > Actually, the same settings can be applied to the CPUs separately, e.g. > > > <scheduler> > > > <param name='fill_rate1'>100</param> > > > <param name='interval1'>1000</param> > > > <cpu id='0'> > > > <param name='idle_time'>1</param> > > > <param name='fill_rate2'>25</param> > > > <param name='interval2'>1000</param> > > > </cpu> > > > </scheduler> > > > should at some point be possible (it's not in the current patch). > > > > Hum, I see, first time I see such fine grained scheduling, good to > > know, thanks ! > > I still find that > > > > <scheduler fill_rate1='100' interval1='1000'> > > <cpu id='0' idle_time='1' fill_rate2='25' interval2='1000'/> > > </scheduler> > > > > would be better than adding the arbitrary <param> element. > > I don't think so - it makes it harder for an app to process, since they > need to know the nams of all the backend specific parameters in order > to extract the attribute. By having individual <params> you can easily > access them all with XPath - eg /domain/schedular/param/@name can > give you a list of all param names very nicely. it also maps to the > virSchedInfo data struct nicely I don't see what is nice with that approach. You the get a node set of attribute coming from different nodes, you need to scan the full tree to get them, then for each attribute you need to find out the value to get the parameter name, then you need to extract the value of the parent. What do you do then with attributes you don't know ? I think code which looks for the set of attributes it knows directly with something like '/domain/scheduler[1]/@fill_rate1' will go straight to the value from an XPath perspective, and make code more readable. But maybe I didn't understood your use case... Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@xxxxxxxxxx | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list