Christoph Egger
2009-May-28 16:42 UTC
[Xen-devel] [PATCH] tools/stubdom: get rid of hardcoded pathes
Hi! Attached patch makes xen-tools and stubdom-dm going independent from hardcoded pathes. It is no possible to install into /usr/local or any other non-default directory and use it out-of-the box. This allows us to have different Xen versions in different directories, simplifies packaging for distributions. It also finds ''hvmloader'' and ''qemu-dm''/''stubdom-dm'' w/o specifying an absolut path. This allows us to migrate guests between Dom0''s where even standard install directories are different (i.e. migrate between Solaris Dom0, NetBSD Dom0 and Linux Dom0). Signed-off-by: Christoph Egger <Christoph.Egger@amd.com> P.S.: Above is only true for PV-guests only until Ian applies my build system patches for ioemu. I''ll resend the ioemu next week since there''s some extra stuff, that isn''t in the earlier patches. -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Thomas M. McCoy, Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Ian Jackson
2009-May-28 18:35 UTC
Re: [Xen-devel] [PATCH] tools/stubdom: get rid of hardcoded pathes
Christoph Egger writes ("[Xen-devel] [PATCH] tools/stubdom: get rid of
hardcoded pathes"):> Attached patch makes xen-tools and stubdom-dm going independent
> >from hardcoded pathes. It is no possible to install into /usr/local or
any
> other non-default directory and use it out-of-the box.
I think this is a laudable goal but I''m not really convinced by the
way you''ve done it. Amongst my comments:
Have you considered an arrangement which substitutes the correct paths
into the relevant scripts at build time, rather than run time ?
Run-time searching can have problems as it means that you can
sometimes find the wrong copy of something if there are multiple
different installs.
> +buildmakevars2file = $(eval $(call buildmakevars2file-closure,$(1)))
> +define buildmakevars2file-closure
> + .PHONY: genpath
> + genpath:
> + rm -f $(1); \
> + echo "SBINDIR=\"$(SBINDIR)\"" >> $(1);
\
> + echo "BINDIR=\"$(BINDIR)\"" >> $(1);
\
This is really very ugly. Surely it would be better to have the
xen-setup[-stumbom] scripts fish things out of the build system,
rather than plumbing everything through the environment like this.
The only thing which _needs_ to be plumbed through from the
commandline or en environment at install-time is DESTDIR or its
equivalent. We can insist on the rest being set in Config.mk or its
ilk.
The paths that stubdom looks at should not vary according to the host
platform. They should be fixed, as they need to be virtualised
anyway.
> --- a/tools/examples/xend-config.sxp Thu May 28 11:07:19 2009 +0100
> +++ b/tools/examples/xend-config.sxp Thu May 28 18:15:43 2009 +0200
> @@ -1,5 +1,7 @@
> # -*- sh -*-
>
> +from xen.util import auxbin
> +
*boggle*
I stopped reading the patch at that point I''m afraid.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Carsten Schiers
2009-May-28 19:49 UTC
[Xen-devel] Xen 3.4 / cpufreq=dom0-kernel / ondemand govenor doesn''t step
I have just upgraded to Xen 3.4 and its kernel. I use
cpufreq=dom0-kernel. I set
the governor to ondemand. In the same setting as Xen 3.3.1 it now
doesn''t step
upwards, even when I create heavy load. Transistion table demonstrates
that:
data://sys/devices/system/cpu/cpu0/cpufreq/stats# cat trans_table
From : To
: 2100000 2000000 1800000 1000000
2100000: 0 0 0 2
2000000: 0 0 0 0
1800000: 0 0 0 0
1000000: 1 0 0 0
after an uptime of 30 minutes. The steps shown here came from a manual
setting
whilst I set the governor back to userspace. Any idea how to check
further?
Does http://xenbits.xensource.com/xen-unstable.hg?rev/674e4d43955f make
any
difference in my case? As said, I used the tarballs.
And by the way: what is the actual xen-3.4 testing, I am a bit lost on
the website.
BR,
Carsten.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
Liu, Jinsong
2009-Jun-01 03:52 UTC
[Xen-devel] RE: Xen 3.4 / cpufreq=dom0-kernel / ondemand govenor doesn''t step
Carsten Schiers wrote:> I have just upgraded to Xen 3.4 and its kernel. I use > cpufreq=dom0-kernel. I set > the governor to ondemand. In the same setting as Xen 3.3.1 it now > doesn''t step > upwards, even when I create heavy load. Transistion table demonstrates > that: > > data://sys/devices/system/cpu/cpu0/cpufreq/stats# cat trans_table > From : To > : 2100000 2000000 1800000 1000000 > 2100000: 0 0 0 2 > 2000000: 0 0 0 0 > 1800000: 0 0 0 0 > 1000000: 1 0 0 0 > > after an uptime of 30 minutes. The steps shown here came from a manual > setting > whilst I set the governor back to userspace. Any idea how to check > further? > > Does http://xenbits.xensource.com/xen-unstable.hg?rev/674e4d43955f > make any > difference in my case? As said, I used the tarballs. > > And by the way: what is the actual xen-3.4 testing, I am a bit lost on > the website. > > BR, > Carsten.Carsten Schiers, Actually xen cpufreq default option is ''cpufreq=xen'', means xen hypervisor will take charge of cpufreq logic, you can try this option. ''cpufreq=dom0-kernel'' means dom0 will take charge of cpufreq logic, but this part was not maintained by me. http://xenbits.xensource.com/xen-unstable.hg?rev/674e4d43955f is not related to ''cpufreq=dom0-kenrel'' option. If you use ''cpufreq=xen'', you can set cpufreq para (governor, speed, sampling-rate, threshold, etc.) by grub cmdline at booting time, or by xenpm tools at runtime. currently xenpm tools implement all para same as you can get&set from native linux /sys/devices/system/cpu/cpux/cpufreq interface. Thanks, Jinsong _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Keir Fraser
2009-Jun-01 07:47 UTC
Re: [Xen-devel] RE: Xen 3.4 / cpufreq=dom0-kernel / ondemand govenor doesn''t step
On 01/06/2009 04:52, "Liu, Jinsong" <jinsong.liu@intel.com> wrote:> Actually xen cpufreq default option is ''cpufreq=xen'', means xen hypervisor > will take charge of cpufreq logic, you can try this option. > ''cpufreq=dom0-kernel'' means dom0 will take charge of cpufreq logic, but this > part was not maintained by me. > > http://xenbits.xensource.com/xen-unstable.hg?rev/674e4d43955f is not related > to ''cpufreq=dom0-kenrel'' option. > > If you use ''cpufreq=xen'', you can set cpufreq para (governor, speed, > sampling-rate, threshold, etc.) by grub cmdline at booting time, or by xenpm > tools at runtime. > currently xenpm tools implement all para same as you can get&set from native > linux /sys/devices/system/cpu/cpux/cpufreq interface....and if you want to pursue cpufreq=dom0-kernel further, Mark Langsdorf is the person to contact. You can find his email address in the changelogs and in the list archives, no doubt. -- Keir _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel
Christoph Egger
2009-Jun-02 09:30 UTC
Re: [Xen-devel] [PATCH] tools/stubdom: get rid of hardcoded pathes
On Thursday 28 May 2009 20:35:17 Ian Jackson wrote:> Christoph Egger writes ("[Xen-devel] [PATCH] tools/stubdom: get rid ofhardcoded pathes"):> > Attached patch makes xen-tools and stubdom-dm going independent > > > > >from hardcoded pathes. It is no possible to install into /usr/local or > > > any > > > > other non-default directory and use it out-of-the box. > > I think this is a laudable goal but I''m not really convinced by the > way you''ve done it. Amongst my comments: > > > Have you considered an arrangement which substitutes the correct paths > into the relevant scripts at build time, rather than run time ?Yes. The build system is doing this.> Run-time searching can have problems as it means that you can > sometimes find the wrong copy of something if there are multiple > different installs.I talked with the python people on irc.freenode.net what is the python way to substitute certain patterns with pathes defined by the build system. The answer: Python has no pre-processor like C. Therefore, have the build system to write the pathes into a file and use them. That is what I do. Neither shell scripts have pre-precessors. So I have to do the same for the hotplug scripts.> > +buildmakevars2file = $(eval $(call buildmakevars2file-closure,$(1))) > > +define buildmakevars2file-closure > > + .PHONY: genpath > > + genpath: > > + rm -f $(1); \ > > + echo "SBINDIR=\"$(SBINDIR)\"" >> $(1); \ > > + echo "BINDIR=\"$(BINDIR)\"" >> $(1); \ > > This is really very ugly. Surely it would be better to have the > xen-setup[-stumbom] scripts fish things out of the build system, > rather than plumbing everything through the environment like this.To avoid maintaining three copies (tools/python/Makefile, stubdom/Makefile and tools/hotplug/common/Makefile) each with its own tweaks and bugs, I moved the code from tools/python/Makfile into a GNU make macro. If you know a better way, tell me.> The only thing which _needs_ to be plumbed through from the > commandline or en environment at install-time is DESTDIR or its > equivalent. We can insist on the rest being set in Config.mk or its > ilk.No, that''s wrong. The way you suggest break the hotplug scripts when you install into a non-default directory.> > The paths that stubdom looks at should not vary according to the host > platform. They should be fixed, as they need to be virtualised > anyway. > > > --- a/tools/examples/xend-config.sxp Thu May 28 11:07:19 2009 +0100 > > +++ b/tools/examples/xend-config.sxp Thu May 28 18:15:43 2009 +0200 > > @@ -1,5 +1,7 @@ > > # -*- sh -*- > > > > +from xen.util import auxbin > > + > > *boggle* > > I stopped reading the patch at that point I''m afraid.That''s necessary to entangle xend from assuming the config files are in /etc. W/o this, you can''t really have a working installation in a non-default directory. Christoph -- ---to satisfy European Law for business letters: Advanced Micro Devices GmbH Karl-Hammerschmidt-Str. 34, 85609 Dornach b. Muenchen Geschaeftsfuehrer: Thomas M. McCoy, Giuliano Meroni Sitz: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 _______________________________________________ Xen-devel mailing list Xen-devel@lists.xensource.com http://lists.xensource.com/xen-devel