Mailing List Archive

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.

-- Keir


> There is a snippet in the xen Makefile like this:
>
> EXTRAEXTRAVERSION=$(subst $(findstring $(EXTRAVERSION),$(shell basename $(TOPDIR))),,$(EXTRAVERSION))
> override EXTRAVERSION:=$(subst linux-$(VERSION).$(PATCHLEVEL).$(SUBLEVEL),,$(shell basename $(TOPDIR)))$(EXTRAEXTRAVERSION)
>
> Now, this probably works fine if the basename of the kernel directory
> is something common. And it is probably perfectly okay to do that in
> the 'make world' Xen builds. But if Xen is treated like 'just another
> kernel patch' or if distributions wish to provide Xen kernels, this is
> a major pain in the ass.
>
> Since the kernel-build directory is not named linux-anything, and
> EXTRAVERSION comes from above, I get this in include/linux/version.h:
>
> #define UTS_RELEASE "2.6.8kernel-source-2.6.8-xen-shiro-1"
>
> If those two lines are commented out in the Makefile, everything looks
> as it should be for a separate build.
>
> Could some sort of an alternative solution to EXTRAVERSION be thought
> of, or atleast a toggle to disable this behaviour?
>
> -- Naked
>
>
>
> -------------------------------------------------------
> 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@lists.sourceforge.net
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> There is a snippet in the xen Makefile like this:
>
> EXTRAEXTRAVERSION=$(subst $(findstring $(EXTRAVERSION),$(shell basename $(TOPDIR))),,$(EXTRAVERSION))
> override EXTRAVERSION:=$(subst linux-$(VERSION).$(PATCHLEVEL).$(SUBLEVEL),,$(shell basename $(TOPDIR)))$(EXTRAEXTRAVERSION)
>
> Now, this probably works fine if the basename of the kernel directory
> is something common. And it is probably perfectly okay to do that in
> the 'make world' Xen builds. But if Xen is treated like 'just another
> kernel patch' or if distributions wish to provide Xen kernels, this is
> a major pain in the ass.

Yeah, I agree, but its very useful.

I propose the following replacement: We test to see whether
there's a .extraversion file, and if so override EXTRAVERSION
with the contents of the file. This should be compatible with
distros and still be convenient for us.

There's already quite a bit of 'diversity' with the way different
architectures deal with handling default configs etc, so I think
we'll get away with this.

I'll make the change unless anyone shouts soon.

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Yeah, I agree, but its very useful.
>
> I propose the following replacement: We test to see whether
> there's a .extraversion file, and if so override EXTRAVERSION
> with the contents of the file. This should be compatible with
> distros and still be convenient for us.
>
> There's already quite a bit of 'diversity' with the way different
> architectures deal with handling default configs etc, so I think
> we'll get away with this.
>
> I'll make the change unless anyone shouts soon.

What a pain in the arse - another file to keep track of. We'd need to
copy an appropriate .extraversion file into each of our build trees
anyway. Might as well just have a command-line-overridable switch as I
suggested, which defaults to somethign sane like "-xen".

-- Keir


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

>
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> >
> > 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.

How many people who build outside our 'make world' environment
actually want a version extension anything other than "-xen"?
I think almost everyone would leave it as the default or specify it
via an external Makefile (like we do!).

I think having yet another config file is more hassle for additional
unwanted flexibility.

-- Keir


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> What a pain in the arse - another file to keep track of. We'd need to
> copy an appropriate .extraversion file into each of our build trees
> anyway. Might as well just have a command-line-overridable switch as I
> suggested, which defaults to somethign sane like "-xen".

We can make the config_* target write .extraversion. I really
don't see how they'd be a problem keeping track of it, and I
think its better than having to remember to put stuff on the make
command line.

If we go with your plan, we'd have to rename our -xen0 kernel to
-xen, otherwise we'd needlessly confuse people who are
reconfiguring their kernel.

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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

>
> > What a pain in the arse - another file to keep track of. We'd need to
> > copy an appropriate .extraversion file into each of our build trees
> > anyway. Might as well just have a command-line-overridable switch as I
> > suggested, which defaults to somethign sane like "-xen".
>
> We can make the config_* target write .extraversion. I really
> don't see how they'd be a problem keeping track of it, and I
> think its better than having to remember to put stuff on the make
> command line.
>
> If we go with your plan, we'd have to rename our -xen0 kernel to
> -xen, otherwise we'd needlessly confuse people who are
> reconfiguring their kernel.

Hmmm, well we can easily support all options, in descending order of
priority:
1. XENVERSION specified on command line
2. Contents of .extraversion file
3. Default to "-xen"

I'll add this to the Linux Makefiles, but I'll leave the root Makefile
using XENVERSION for now. You can change it to use .extraversion if
you care. :-)

-- Keir


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Ian Pratt wrote:
> 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.

Keir Fraser wrote:
> Hmmm, well we can easily support all options, in descending order of
> priority:
> 1. XENVERSION specified on command line
> 2. Contents of .extraversion file
> 3. Default to "-xen"
>
> I'll add this to the Linux Makefiles, but I'll leave the root
> Makefile using XENVERSION for now. You can change it to use
> .extraversion if you care. :-)

Um, I haven't ever really looked into 'make world' so I don't know
what it is that really requires all this.

But, is there something wrong with using the normal kernel facilities
for this thing?

The default behaviour is that EXTRAVERSION on the command-line
overrides '.extraversion'.

So create the .extraversion file in the directories where you wish to
allow the user to rebuild from the command-line - and just pass
EXTRAVERSION on the make invocation line for builds where you do not
need it.

I am probably missing something, but I don't see the reason for
XENVERSION at all?

(And for a distribution, xen0 and xenU kernels are probably already
very well separated, so that extraversion is not needed for them - for
example, this Debian package I created is named:

kernel-xen0-2.6.8-shiro-1

when EXTRAVERSION was -shiro-1 and I compiled a domain 0 kernel.)

-- Naked



-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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@lists.sourceforge.net
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> Hmmm, well we can easily support all options, in descending order of
> priority:
> 1. XENVERSION specified on command line
> 2. Contents of .extraversion file
> 3. Default to "-xen"
>
> I'll add this to the Linux Makefiles, but I'll leave the root Makefile
> using XENVERSION for now. You can change it to use .extraversion if
> you care. :-)

I think I've changed my mind on this, and have a much better plan:

We shouldn't monkey with EXTRAVERSION at all, but just leave
what's set in the linux toplevel Makefile. We should then have
our top-level Xen build script patch the Makefiles in the linux
build trees as appropriate.

This scheme wins because a) it is 100% compatible with what
distros etc want to do (they use extraversion for their own
purposes); b) doesn't change the current behaviour from a users
POV (i.e. no setting of XENVERSION required); c) is closest to
standard i386 linux; d) requires least Makefile magic.

A clear cut winner if ever I saw one...


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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

*nod* sounds fine to me. SHould continue to work just fine with my
conversion of the sparse tree to a unified diff as well as doesn't step
on xenlinux-builder's toes (as well as Debian's). ;)

On Sat, 2004-10-23 at 09:05, Ian Pratt wrote:
> > Hmmm, well we can easily support all options, in descending order of
> > priority:
> > 1. XENVERSION specified on command line
> > 2. Contents of .extraversion file
> > 3. Default to "-xen"
> >
> > I'll add this to the Linux Makefiles, but I'll leave the root Makefile
> > using XENVERSION for now. You can change it to use .extraversion if
> > you care. :-)
>
> I think I've changed my mind on this, and have a much better plan:
>
> We shouldn't monkey with EXTRAVERSION at all, but just leave
> what's set in the linux toplevel Makefile. We should then have
> our top-level Xen build script patch the Makefiles in the linux
> build trees as appropriate.
>
> This scheme wins because a) it is 100% compatible with what
> distros etc want to do (they use extraversion for their own
> purposes); b) doesn't change the current behaviour from a users
> POV (i.e. no setting of XENVERSION required); c) is closest to
> standard i386 linux; d) requires least Makefile magic.
>
> A clear cut winner if ever I saw one...
>
>
> 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@lists.sourceforge.net
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

We distribute sparse source trees because they are convenenient to
develop with (the BK repositories are primarily geared for
development). Probably also distributing script(s) to cook the
directories into sane diffs or whatever would be useful.

It sounds to me like, now you have your scripts written, that the
hassle is over --- just start your script and make a cup of coffee?
:-) If not, where does the ongoing trouble arise from?

-- Keir

> 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


-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Yes, this is better actually. I've updated the repository
appropriately.

-- Keir

> I think I've changed my mind on this, and have a much better plan:
>
> We shouldn't monkey with EXTRAVERSION at all, but just leave
> what's set in the linux toplevel Makefile. We should then have
> our top-level Xen build script patch the Makefiles in the linux
> build trees as appropriate.
>
> This scheme wins because a) it is 100% compatible with what
> distros etc want to do (they use extraversion for their own
> purposes); b) doesn't change the current behaviour from a users
> POV (i.e. no setting of XENVERSION required); c) is closest to
> standard i386 linux; d) requires least Makefile magic.
>
> A clear cut winner if ever I saw one...
>
>
> 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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

In fact, at least for the 2.6 tree, isn't creating a self-contained
diff as simple as something like:
tar xzf linux-2.6.8.1.tar.gz
cp -a linux-2.6.8.1 linux-2.6.8.1-xen
cd linux-2.6.8.1-xen-sparse
for i in `find . -type f | grep -v SCCS` ; do \
cp $i ../linux-2.6.8.1-xen/$i ; done
cd ..
rm -f linux-2.6.8.1-xen/mkbuildtree
cp -a xen/include/hypervisor-ifs linux-2.6.8.1-xen/include/asm-xen
diff -urP linux-2.6.8.1 linux-2.6.8.1-xen >linux-2.6.8.1-xen-patch

? :-)

-- Keir

>
> We distribute sparse source trees because they are convenenient to
> develop with (the BK repositories are primarily geared for
> development). Probably also distributing script(s) to cook the
> directories into sane diffs or whatever would be useful.
>
> It sounds to me like, now you have your scripts written, that the
> hassle is over --- just start your script and make a cup of coffee?
> :-) If not, where does the ongoing trouble arise from?
>
> -- Keir
>
> > 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



-------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

>In fact, at least for the 2.6 tree, isn't creating a self-contained
>diff as simple as something like:
> tar xzf linux-2.6.8.1.tar.gz
> cp -a linux-2.6.8.1 linux-2.6.8.1-xen
> cd linux-2.6.8.1-xen-sparse
> for i in `find . -type f | grep -v SCCS` ; do \
> cp $i ../linux-2.6.8.1-xen/$i ; done

Well instead of the find actually need something like:

tar cvf - --exclude SCCS --exclude mkbuildtree . | \
tar -C../linux-2.6.8.1-xen -xvf -

(to deal with non-existant directories in the desintation).

> cd ..
> rm -f linux-2.6.8.1-xen/mkbuildtree
> cp -a xen/include/hypervisor-ifs linux-2.6.8.1-xen/include/asm-xen

And instead of the above can use:

cd ../xen/include
tar cvf - --exclude SCCS . | \
tar -C../../linux-2.6.8.1-xen/include/asm-xen -xvf -

which just ensures get rid of SCCS directories.


> diff -urP linux-2.6.8.1 linux-2.6.8.1-xen >linux-2.6.8.1-xen-patch
>
>? :-)

Otherwise basically works; I've put a patch in this form on

http://www.cl.cam.ac.uk/~smh22/linux-2.6.8.1-xen-patch

in case anyone's interested.

We should probably update the nightly build scripts to dump one of
these on the standard download page...

cheers,

S.

>
>>In fact, at least for the 2.6 tree, isn't creating a self-contained
>>diff as simple as something like:
>> tar xzf linux-2.6.8.1.tar.gz
>> cp -a linux-2.6.8.1 linux-2.6.8.1-xen
>> cd linux-2.6.8.1-xen-sparse
>> for i in `find . -type f | grep -v SCCS` ; do \
>> cp $i ../linux-2.6.8.1-xen/$i ; done
>
>Well instead of the find actually need something like:
>
> tar cvf - --exclude SCCS --exclude mkbuildtree . | \
> tar -C../linux-2.6.8.1-xen -xvf -
>
>(to deal with non-existant directories in the desintation).
>
>> cd ..
>> rm -f linux-2.6.8.1-xen/mkbuildtree
>> cp -a xen/include/hypervisor-ifs linux-2.6.8.1-xen/include/asm-xen
>
>And instead of the above can use:
>
> cd ../xen/include
> tar cvf - --exclude SCCS . | \
^^^^

This should of course be

tar cvf - --exclude SCCS hypervisor-ifs | \

:-)

On Sat, 23 Oct 2004, Ian Pratt wrote:

>
> > There is a snippet in the xen Makefile like this:
> >
> > EXTRAEXTRAVERSION=$(subst $(findstring $(EXTRAVERSION),$(shell basename $(TOPDIR))),,$(EXTRAVERSION))
> > override EXTRAVERSION:=$(subst linux-$(VERSION).$(PATCHLEVEL).$(SUBLEVEL),,$(shell basename $(TOPDIR)))$(EXTRAEXTRAVERSION)
> >
> > Now, this probably works fine if the basename of the kernel directory
> > is something common. And it is probably perfectly okay to do that in
> > the 'make world' Xen builds. But if Xen is treated like 'just another
> > kernel patch' or if distributions wish to provide Xen kernels, this is
> > a major pain in the ass.
>
> Yeah, I agree, but its very useful.
>
> I propose the following replacement: We test to see whether
> there's a .extraversion file, and if so override EXTRAVERSION
> with the contents of the file. This should be compatible with
> distros and still be convenient for us.

2.6 uses .localversion files.


-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel