[Libvir] [PATCH] virsh Range check in Credit Scheduler
Hi, Add Range check in Credit Scheduler. Signed-off-by: Atsushi SAKAI <sakaia@jp.fujitsu.com> Thanks Atsushi SAKAI
On Tue, Jul 17, 2007 at 11:16:24AM +0100, Richard W.M. Jones wrote:
Atsushi SAKAI wrote:
Hi,
Add Range check in Credit Scheduler.
Hum, it's true that this code is really specific to Xen at this point in virsh.c But I think the long term way is to add that check where it can really be done without adding more hypervisor specific code to virsh.c, could you rewrite the patch to actually make the check where it belongs in xenHypervisorSetSchedulerParameters() in src/xen_internal.c, that way not only virsh is protected but also any other app using the API to do scheduling tuning, thanks in advance, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel uint16(weight and cap) is copyied in src/virsh.c so It cannot rewrite on src/xen_internal.c. Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Tue, Jul 17, 2007 at 11:16:24AM +0100, Richard W.M. Jones wrote:
Atsushi SAKAI wrote:
Hi,
Add Range check in Credit Scheduler.
Hum, it's true that this code is really specific to Xen at this point in virsh.c But I think the long term way is to add that check where it can really be done without adding more hypervisor specific code to virsh.c, could you rewrite the patch to actually make the check where it belongs in xenHypervisorSetSchedulerParameters() in src/xen_internal.c, that way not only virsh is protected but also any other app using the API to do scheduling tuning,
thanks in advance,
Daniel
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Jul 18, 2007 at 09:11:42AM +0900, Atsushi SAKAI wrote:
Hi, Daniel
uint16(weight and cap) is copyied in src/virsh.c so It cannot rewrite on src/xen_internal.c.
xenHypervisorSetSchedulerParameters() do get the int values in the case XEN_SCHEDULER_CREDIT : op_dom.u.getschedinfo.u.credit.weight = params[i].value.ui; and op_dom.u.getschedinfo.u.credit.cap = params[i].value.ui; the ui field is an unsigned long. the test against the value 1 to USHRT_MAX can be done there and the case where one have a negative value at the virsh level would correspond to an extremely large integer in xenHypervisorSetSchedulerParameters() after the unsigned cast. See the enclosed patch, please check, thanks, Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Hi, Daniel I checked it and it works fine! 2 point of question (not related to this point) 1)I sometimes rewiriting xen_internal.c in my test environment. from xen/linux/privcmd.h to xen/sys/privcmd.h Is there any possibility to change the path? 2)xen-unstable 15482 changes sysctl version(from 3 to 4). Is there any possibility libvirt to work new sysctl version? At this moment, libvirt cannot not handle latest xen-unstable. Thanks Atsushi SAKAI Daniel Veillard <veillard@redhat.com> wrote:
On Wed, Jul 18, 2007 at 09:11:42AM +0900, Atsushi SAKAI wrote:
Hi, Daniel
uint16(weight and cap) is copyied in src/virsh.c so It cannot rewrite on src/xen_internal.c.
xenHypervisorSetSchedulerParameters() do get the int values in the case XEN_SCHEDULER_CREDIT : op_dom.u.getschedinfo.u.credit.weight = params[i].value.ui; and op_dom.u.getschedinfo.u.credit.cap = params[i].value.ui;
the ui field is an unsigned long. the test against the value 1 to USHRT_MAX can be done there and the case where one have a negative value at the virsh level would correspond to an extremely large integer in xenHypervisorSetSchedulerParameters() after the unsigned cast.
See the enclosed patch, please check,
thanks,
Daniel
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Atsushi SAKAI wrote:
1)I sometimes rewiriting xen_internal.c in my test environment. from xen/linux/privcmd.h to xen/sys/privcmd.h Is there any possibility to change the path?
Atsushi, Can you test the attached patch to see if it fixes this problem for you? Thanks, Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Wed, Jul 18, 2007 at 03:17:20PM +0100, Richard W.M. Jones wrote:
Can you test the attached patch to see if it fixes this problem for you?
It's much preferred to test xen/sys/privcmd.h first. This is what is used with current Xen onwards, i.e. xen/linux/privcmd.h should only be a fallback, not preferred. regards john
John Levon wrote:
On Wed, Jul 18, 2007 at 03:17:20PM +0100, Richard W.M. Jones wrote:
Can you test the attached patch to see if it fixes this problem for you?
It's much preferred to test xen/sys/privcmd.h first. This is what is used with current Xen onwards, i.e. xen/linux/privcmd.h should only be a fallback, not preferred.
Updated patch, just swaps the order of the tests. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Wed, Jul 18, 2007 at 03:48:55PM +0100, Richard W.M. Jones wrote:
John Levon wrote:
On Wed, Jul 18, 2007 at 03:17:20PM +0100, Richard W.M. Jones wrote:
Can you test the attached patch to see if it fixes this problem for you?
It's much preferred to test xen/sys/privcmd.h first. This is what is used with current Xen onwards, i.e. xen/linux/privcmd.h should only be a fallback, not preferred.
Updated patch, just swaps the order of the tests.
+1 looks good to me. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Hi, Rich It works fine for me! Thank you! Anyway, Tab and Space is different line by line. 1st point + AC_CHECK_HEADERS(xen/xen.h xen/version.h xen/dom0_ops.h,,[ + AC_MSG_ERROR([Cannot find standard Xen headers. Is xen-devel installed?]) 2nd point + dnl Search for the location of <xen/{linux,sys}/privcmd.h>. + AC_CHECK_HEADERS(xen/sys/privcmd.h,,[ + AC_CHECK_HEADERS(xen/linux/privcmd.h,,[ + AC_MSG_ERROR([Cannot find header file <xen/linux/privcmd.h> or <xen/sys/privcmd.h>. Is xen-devel installed?]) + ], Thanks Atsushi SAKAI "Richard W.M. Jones" <rjones@redhat.com> wrote:
John Levon wrote:
On Wed, Jul 18, 2007 at 03:17:20PM +0100, Richard W.M. Jones wrote:
Can you test the attached patch to see if it fixes this problem for you?
It's much preferred to test xen/sys/privcmd.h first. This is what is used with current Xen onwards, i.e. xen/linux/privcmd.h should only be a fallback, not preferred.
Updated patch, just swaps the order of the tests.
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Atsushi SAKAI wrote:
Hi, Rich
It works fine for me! Thank you!
Atsushi, thanks for testing this. I've applied that change to CVS. If you are using the CVS version, make sure to run autogen.sh again after the check out. Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Hi, Rich Thank you for writing and committing your patch. I use CVS version as you suggested (use autogen.sh) And current version compiles fine! Thanks Atsushi SAKAI "Richard W.M. Jones" <rjones@redhat.com> wrote:
Atsushi SAKAI wrote:
Hi, Rich
It works fine for me! Thank you!
Atsushi, thanks for testing this. I've applied that change to CVS.
If you are using the CVS version, make sure to run autogen.sh again after the check out.
Rich.
-- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
On Wed, Jul 18, 2007 at 10:40:06PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
I checked it and it works fine!
Okay, commited. W.r.t. your question of compatibility with xen-unstable, I didn't looked at it. Seems someone need to check the compatibility again once they produce a new release. Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, Jul 18, 2007 at 10:40:06PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
?$B!!I checked it and it works fine!
2 point of question (not related to this point)
1)I sometimes rewiriting xen_internal.c in my test environment. from xen/linux/privcmd.h to xen/sys/privcmd.h Is there any possibility to change the path?
2)xen-unstable 15482 changes sysctl version(from 3 to 4). Is there any possibility libvirt to work new sysctl version? At this moment, libvirt cannot not handle latest xen-unstable.
Looks like a pretty trivial thing to fix @@ -85,6 +86,23 @@ struct xen_sysctl_physinfo { uint64_aligned_t free_pages; uint64_aligned_t scrub_pages; uint32_t hw_cap[8]; + + /* IN/OUT variables. */ + /* + * IN: maximum addressable entry in the caller-provided cpu_to_node array. + * OUT: largest cpu identifier in the system. + * If OUT is greater than IN then the cpu_to_node array is truncated! + */ + uint32_t max_cpu_id; + /* + * If not NULL, this array is filled with node identifier for each cpu. + * If a cpu has no node information (e.g., cpu not present) then the + * sentinel value ~0u is written. + * The size of this array is specified by the caller in @max_cpu_id. + * If the actual @max_cpu_id is smaller than the array then the trailing + * elements of the array will not be written by the sysctl. + */ + XEN_GUEST_HANDLE_64(uint32_t) cpu_to_node; }; So the struct basically grew 12 bytes larger. I guess libvirt is broken because we're not passing in a big enough memory block. Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
Hi, Dan Thank you for your suggestion. My concern is if patch for sysctl v4 is applied or not. Since previously Daniel commented, libvirt does not include the patch for Xen-unstable only includes for versioned like Xen-3.x. Thanks Atsushi SAKAI "Daniel P. Berrange" <berrange@redhat.com> wrote:
On Wed, Jul 18, 2007 at 10:40:06PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
?$B!!I checked it and it works fine!
2 point of question (not related to this point)
1)I sometimes rewiriting xen_internal.c in my test environment. from xen/linux/privcmd.h to xen/sys/privcmd.h Is there any possibility to change the path?
2)xen-unstable 15482 changes sysctl version(from 3 to 4). Is there any possibility libvirt to work new sysctl version? At this moment, libvirt cannot not handle latest xen-unstable.
Looks like a pretty trivial thing to fix
@@ -85,6 +86,23 @@ struct xen_sysctl_physinfo { uint64_aligned_t free_pages; uint64_aligned_t scrub_pages; uint32_t hw_cap[8]; + + /* IN/OUT variables. */ + /* + * IN: maximum addressable entry in the caller-provided cpu_to_node array. + * OUT: largest cpu identifier in the system. + * If OUT is greater than IN then the cpu_to_node array is truncated! + */ + uint32_t max_cpu_id; + /* + * If not NULL, this array is filled with node identifier for each cpu. + * If a cpu has no node information (e.g., cpu not present) then the + * sentinel value ~0u is written. + * The size of this array is specified by the caller in @max_cpu_id. + * If the actual @max_cpu_id is smaller than the array then the trailing + * elements of the array will not be written by the sysctl. + */ + XEN_GUEST_HANDLE_64(uint32_t) cpu_to_node; };
So the struct basically grew 12 bytes larger. I guess libvirt is broken because we're not passing in a big enough memory block.
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
On Mon, Jul 30, 2007 at 11:52:16AM +0900, Atsushi SAKAI wrote:
Hi, Dan
Thank you for your suggestion. My concern is if patch for sysctl v4 is applied or not. Since previously Daniel commented, libvirt does not include the patch for Xen-unstable only includes for versioned like Xen-3.x.
Well, since they correctly changed the interface version, I think this is okay to track that change. I just don't want to try to track every possible interface change they would not label as such. That change has been commited on their side for a while now, so I guess it's there for good too, plus as Dan pointed out the change could be rather minimal, so let's do it. Daniel
"Daniel P. Berrange" <berrange@redhat.com> wrote:
On Wed, Jul 18, 2007 at 10:40:06PM +0900, Atsushi SAKAI wrote:
Hi, Daniel
?$B!!I checked it and it works fine!
2 point of question (not related to this point)
1)I sometimes rewiriting xen_internal.c in my test environment. from xen/linux/privcmd.h to xen/sys/privcmd.h Is there any possibility to change the path?
2)xen-unstable 15482 changes sysctl version(from 3 to 4). Is there any possibility libvirt to work new sysctl version? At this moment, libvirt cannot not handle latest xen-unstable.
Looks like a pretty trivial thing to fix
@@ -85,6 +86,23 @@ struct xen_sysctl_physinfo { uint64_aligned_t free_pages; uint64_aligned_t scrub_pages; uint32_t hw_cap[8]; + + /* IN/OUT variables. */ + /* + * IN: maximum addressable entry in the caller-provided cpu_to_node array. + * OUT: largest cpu identifier in the system. + * If OUT is greater than IN then the cpu_to_node array is truncated! + */ + uint32_t max_cpu_id; + /* + * If not NULL, this array is filled with node identifier for each cpu. + * If a cpu has no node information (e.g., cpu not present) then the + * sentinel value ~0u is written. + * The size of this array is specified by the caller in @max_cpu_id. + * If the actual @max_cpu_id is smaller than the array then the trailing + * elements of the array will not be written by the sysctl. + */ + XEN_GUEST_HANDLE_64(uint32_t) cpu_to_node; };
So the struct basically grew 12 bytes larger. I guess libvirt is broken because we're not passing in a big enough memory block.
Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|
-- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Wed, 18 Jul 2007 04:16:36 -0400 Daniel Veillard wrote:
On Wed, Jul 18, 2007 at 09:11:42AM +0900, Atsushi SAKAI wrote:
Hi, Daniel
uint16(weight and cap) is copyied in src/virsh.c so It cannot rewrite on src/xen_internal.c.
xenHypervisorSetSchedulerParameters() do get the int values in the case XEN_SCHEDULER_CREDIT : op_dom.u.getschedinfo.u.credit.weight = params[i].value.ui; and op_dom.u.getschedinfo.u.credit.cap = params[i].value.ui;
the ui field is an unsigned long. the test against the value 1 to USHRT_MAX can be done there and the case where one have a negative value at the virsh level would correspond to an extremely large integer in xenHypervisorSetSchedulerParameters() after the unsigned cast.
See the enclosed patch, please check,
Hi, The schedinfo command said strange message. # virsh schedinfo 25 --weight 0 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler weight parameter (%d) is out of range (1-65535) ^^^^here # virsh schedinfo 25 --cap -1 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (%d) is out of range (0-65535) ^^^^here I think we do not need to print the specified number, so I removed "(%d)" from the code to solve this problem. If you want to print the specified number, I will remake this patch ! And I found some wrong code when I was checking about error message. So I fix them, but if I have a misunderstanding of them, please tell me. :-) o I guess 10th argument of __virRaiseError should be specified the number of the line. But the value, for example which is number of heypercall, is sometimes specified. --- xen_internal.c-673- errmsg = __virErrorMsg(error, info); xen_internal.c:674: __virRaiseError(NULL, NULL, NULL, VIR_FROM_XEN, error, VIR_ERR_ERROR, xen_internal.c-675- errmsg, info, NULL, value, 0, errmsg, info); xen_internal.c-676-} There is same mistake at xml.c, xmlrpc.c and xend_internal.c, too. Thanks, Saori Fukuta
On Fri, Jul 20, 2007 at 05:17:34PM +0900, Saori Fukuta wrote:
The schedinfo command said strange message. # virsh schedinfo 25 --weight 0 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler weight parameter (%d) is out of range (1-65535) ^^^^here # virsh schedinfo 25 --cap -1 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (%d) is out of range (0-65535) ^^^^here
I think we do not need to print the specified number, so I removed "(%d)" from the code to solve this problem. If you want to print the specified number, I will remake this patch !
That would be nicer, we have the information and don't pass it to the user. It may not be a big gain when used purely from virsh but for future automatic tuning tools it may be interesting to get the value reported back. An snprintf to a local buffer to generate the string may be sufficient. I didn't applied remove_perD.patch for this reason, if you send another patch I will fix this or I could just do it.
And I found some wrong code when I was checking about error message. So I fix them, but if I have a misunderstanding of them, please tell me. :-) o I guess 10th argument of __virRaiseError should be specified the number of the line. But the value, for example which is number of heypercall, is sometimes specified.
Well not really it's just str1 - str3/int1 - int2 are just extra informations. This is intended to populate the virError fields to be used for more precise error handling than the default one.
xen_internal.c-673- errmsg = __virErrorMsg(error, info); xen_internal.c:674: __virRaiseError(NULL, NULL, NULL, VIR_FROM_XEN, error, VIR_ERR_ERROR, xen_internal.c-675- errmsg, info, NULL, value, 0, errmsg, info); xen_internal.c-676-}
There is same mistake at xml.c, xmlrpc.c and xend_internal.c, too.
There is still some point of the patch which make sense, for example adding value at the end of the argument list in virXenError(), I will apply some of those but not remove the tenth value. thanks, and sorry for the mistake in xen_internal.c Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
On Fri, 20 Jul 2007 05:00:41 -0400 Daniel Veillard wrote:
On Fri, Jul 20, 2007 at 05:17:34PM +0900, Saori Fukuta wrote:
The schedinfo command said strange message. # virsh schedinfo 25 --weight 0 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler weight parameter (%d) is out of range (1-65535) ^^^^here # virsh schedinfo 25 --cap -1 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (%d) is out of range (0-65535) ^^^^here
That would be nicer, we have the information and don't pass it to the user. It may not be a big gain when used purely from virsh but for future automatic tuning tools it may be interesting to get the value reported back. An snprintf to a local buffer to generate the string may be sufficient. I didn't applied remove_perD.patch for this reason, if you send another patch I will fix this or I could just do it.
OK, I understand the purpose of passing it. I simply added snprintf. How about this ? # ./virsh schedinfo 25 --weight 0 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler weight parameter (0) is out of range (1-65535) # ./virsh schedinfo 25 --cap -1 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (-1) is out of range (0-65535)
And I found some wrong code when I was checking about error message. So I fix them, but if I have a misunderstanding of them, please tell me. :-) o I guess 10th argument of __virRaiseError should be specified the number of the line. But the value, for example which is number of heypercall, is sometimes specified.
Well not really it's just str1 - str3/int1 - int2 are just extra informations. This is intended to populate the virError fields to be used for more precise error handling than the default one.
There is still some point of the patch which make sense, for example adding value at the end of the argument list in virXenError(), I will apply some of those but not remove the tenth value.
Thank you for explaining ! Saori.
On Fri, Jul 20, 2007 at 07:10:12PM +0900, Saori Fukuta wrote:
That would be nicer, we have the information and don't pass it to the user. It may not be a big gain when used purely from virsh but for future automatic tuning tools it may be interesting to get the value reported back. An snprintf to a local buffer to generate the string may be sufficient. I didn't applied remove_perD.patch for this reason, if you send another patch I will fix this or I could just do it.
OK, I understand the purpose of passing it. I simply added snprintf. How about this ?
# ./virsh schedinfo 25 --weight 0 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler weight parameter (0) is out of range (1-65535)
# ./virsh schedinfo 25 --cap -1 libvir: Xen error : invalid argument in xenHypervisorSetSchedulerParameters: Credit scheduler cap parameter (-1) is out of range (0-65535)
Great, applied and commited, thanks ! Daniel -- Red Hat Virtualization group http://redhat.com/virtualization/ Daniel Veillard | virtualization library http://libvirt.org/ veillard@redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
participants (6)
-
Atsushi SAKAI -
Daniel P. Berrange -
Daniel Veillard -
John Levon -
Richard W.M. Jones -
Saori Fukuta