[Pkg-xen-devel] Bug#536174: Bug#536174: Bug#536174: Bug#536174: xen-utils-3.4: pygrub searches for filesystem plugins at the wrong path

[Thomas Goirand]

Ian Campbell wrote:
> On Sun, 2009-07-19 at 04:25 +0800, Thomas Goirand wrote:
>> In both cases, the goal is to avoid forking yet another process, by
>> calling "xm list", "xm stop" or "xm start" for example, by simply
>> including some python code and calling the main. 
> 
> FWIW I'd be surprised if the upstream Xen developers would consider this
> to be a stable/exported interface.
> 
> Is performance of "xm start" and "xm stop" really bounded by the time it
> takes to fork the python process for xm? Seems unlikely to me. Similarly
> if time to fork "xm list" is an issue then perhaps you are polling far
> to frequently?
> 
> Ian.

You got the main reason by yourself! We are doing "xm list" every minute
because we are graphing the resulting time in a RRD (remotely, not on
the dom0). The issue is not only the time to execute, but mainly the
memory usage going up and down all the time when calling them.

Anyway, we are not the only one doing this. The decision to use what's
in /usr/lib/xen anyway is not yours. I agree it's not good, we are
moving away from it. In fact, we should never have had a look at the bad
example from Enomalism. But the issue remains anyway. It's not up to
Debian maintainers to decide things should be different from other
distributions, or even from the source version of Xen, and that is it
(even if you consider using it ugly...), IMHO.

Thomas

P.S: thanks a lot for the huge work maintaining Xen in Debian, it's far
from being trivial. Hoping that you guys will have enough time so there
will be soon a 64 bits dom0 running kernel 2.6.28 or 2.6.30 in Debian,
as we are having drivers issues with 2.6.26 (I managed to get a patch
for our e1000e 82574L go to the kernel team, it's tested and working
very well even in production, but not sure when or if it's going to be
included).