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(a)redhat.com | libxml GNOME XML XSLT toolkit
http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine
http://rpmfind.net/