[PATCH] Make non-native python path handling a
> > Although I don't really agree with the installing of the
> > python bits to the non-native paths, I can see where it's
> > useful as long as the module ABI doesn't change if you're
> > trying to distribute binary tarballs. But with the current
> > handling it adds module lookup costs for the native path case
> > (which would be the norm) as well as prevents using
> > PYTHONPATH to look to a different location for the modules.
> >
> > The attached patch changes things so that at first, the xen
> > module is attempted to be imported from the stock paths. If
> > we get an ImportError exception, then it adds /usr/lib/python
> > to the end of the python path and imports again.
>
> Do you prefer this to just unconditionally addding /usr/lib/python to
> the end of the path rather than the front?
Slightly, but just because having /usr/lib/python in my sys.path is
ugly :-) I can look over it, though... patch doing that attached
Signed-off-by: Jeremy Katz <katzj@redhat.com>
===== tools/misc/netfix 1.13 vs edited =====
[PATCH] add-build.patch
Add build targets to all makefiles. Debian does builds as non-root, so
it's better to do as much as possible before requiring root privs.
Signed-off-by: Adam Heath <doogie@brainfood.com>
Name: tools-misc-TARGETS.patch
Description: Split compile/link stages
distcc behaves much better when you compile and link in 2 separate steps.
Plus, this is a more standard way of doing things.
Signed-off-by: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Description: use DESTDIR correctly
Standard makefiles always attempt to install to the root(/). Setting
DESTDIR is the normal way to install to an alternative location.
Setting prefix has the possibility of breaking programs, as the prefix
may have been embedded inside a compiled binary.
From: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Description: use INSTALL everywhere
Use install(by way of INSTALL variables) to create directories, install
programs, and install data files.
From: Adam Heath <doogie@brainfood.com>
Signed-off-by: ian.pratt@cl.cam.ac.uk
Clean up public XenLinux header files. Now accessible from userspace as
#include <xen/linux...>
Got rid of the linux-xen-sparse symlink as it's no longer needed.
David Becker writes:
This patch adds support for high memory to /proc/xen/memory_target,
and it restores the mem= linux boot parameter. This is for 2.4.26 only.
I haven't looked at 2.6 yet. (remmeber that CONFIG_HIGHMEM
is not on by default in the xen0 and xenU configs)
I have racks of 2g and 4g machines, hence my interest.
The 'mem=' param tells linux the maximum amount of memory it can use.
The feature originated for hosts where the normal mem detection mechanisms
failed. These days its main use in stock linux is to artificially
constrain how much memory linux uses for testing low memory systems.
With this patch, mem= now means the max memory linux could ever use.
When a domain is created with less than that the mem= value, linux will
behave as though that 'missing' memory is 'allocated'. To give the
domain more memory, first run setdomainmaxmem in Dom-0 to raise Xen's
limit, then write the new total to /proc/xen/memory_target in the
domain. When mem= is not explicitly set, it defaults to the
boottime size of the domain.
dom-0# xm create name=dom-1 memory=100 extra='-b mem=2g'
dom-0# setdomainmaxmem 1 2g
dom-1# echo 2g > /proc/xen/memory_target
