Ok, after writing this, I decided to add thisheader, warning mini-rant
follows. ;-P
Personally, I compile about 7 or 8 different kernels, with 3 different
unfied diff patches and modules options to completely setup my cluster.
SO, doing it inside make world, is a really ugly option. Hence writing
xenlinuxbuilder.
To be completely honest, I dislike the curent sparse patchfile setup
with a passion. 8-P It's a RPITA to work with when packaging xen for
Debian (or other distros that uses src tree patches for their main
kernels) and for creating multiple kernels using different unified diff
patch files for each kernel. I have to copy the linux source tree 4
times to get a clean patch of xen+distro patches as a unified diff since
debian distributes kernel-source-* with their patches already in it (I'm
certain other distros have their own patches as well) to keep from a:
blowing up the debian source tree (this is partly debian's fault, sinc e
it distributs a patched kernel source instead of pristine that's then
patched to get debian's kernels).
I understand why it's a sparse patch file, reduces bulk by quite a bit.
But It's darn unfriendly when you want to compile both 2.4 and 2.6
kernels along with your distros patches. 8-P Not to to mention the fact
that it walks ALL over any distro kernel src tree that's been patched
since it replaces a few of the standard distro files outright. 8-P
If you want any part of xenlinuxbuilder for the xen distro, feel free to
grab it. It's GPLd (hell, I'll special license as bsd if necessary).
Same thing with anythign in the debian packaging from debian/*. It's
just another Makefile. The only real debian specific part is the tarball
location for the kernel source and the xen_patch_ver check function.
But please, for the love of my sanity and other distro's (besides
redhat) can we take a really hard look at the patches beyond just the
extraversion being a bummer? :) Like providing a tool with the xen
tarball for creating the kernels? Or even a faster conversion of the
sparse patchfile to a unified diff that can then be applied to separate
kernel trees without linking back into the xen headers? (maybe a bit
more inteligent in my debian packaging on how much of the kernel tree to
unpack, patch, copy, diff, repeat...?) Symlinks of directories can be
SUCH a PITA when patching after xen. As can the complete replacement of
individual files. 8-P
If not, i'll just continue to do the conversion at packaging time and
smile nicely. :) Sometimes a package like xen is worth some extra steps
to get it packaged fo ryour distro.
Sorry for the rant, this was the largest part of packaging xen, getting
the patchfile converted to a diff and playing nice with other patches
without the end user having to think about sparse vs diff ordering and
care.
If i'm just being completely boneheaded here, just smack me and send me
back to pascal 101. ;-P If i'm not being a bonehead, I'll start looking
into a more inteligent method of converting things so it's faster and
can be made a part of the xen dist files.
Brian Wolfe
On Sat, 2004-10-23 at 06:15, Ian Pratt wrote:
> >
> > Yeah, playing with the directory name is gross!
> >
> > I'm trying out replacing this with:
> > XENVERSION ?= -xen
> > EXTRAVERSION := $(EXTRAVERSION)$(XENVERSION)
> >
> > I've then changed the repository makefile to override XENVERSION with
> > -xenU or -xen0 as appropriate. If it works as expected I'll check it
> > in.
>
> That's going to be a pain to remember to set XENVERSION on the
> command line if we're building directly within the kernel
> directory, which people do all the time (e.g. after changing the
> config on a kernel). I think 'baking' the extraversion into the
> tree via a .extraversion file is the best soloution.
>
> Ian
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
> Use IT products in your business? Tell us what you think of them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
-------------------------------------------------------
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
Home