kernel versions on Linus bk tree

kernel versions on Linus bk tree

[Jon Smirl]

I just came across a problem with the way the kernel is being
versioned. The DRM driver needs an IFDEF for the four level page table
change depending on kernel version built against. I used this:
#if LINUX_VERSION_CODE < 0x02060a

The problem is that 2.6.10 was released on kernel.org without the four
level change. But Linus bk which also has version 2.6.10 has the
change. Is there some way around this problem?

One solution would be to bump the version in Linus bk to 2.6.11-rc1 on
the first check in after 2.6.10 is cut. The general case of this would
be to always bump the Linus bk version number immediately after
cutting the released version.

I've been bitten by this ambiguity before when kernels from Linus BK
have more code in them than the one from kernel.org and have the same
version number. Changing the timing of the version bump would lessen
this problem since kernels complied from Linus bk tend to have a short
life.


-- 
Jon Smirl
jonsmirl@gmail.com

Re: kernel versions on Linus bk tree

[Vincent Hanquez]

On Sat, Jan 08, 2005 at 01:23:20PM -0500, Jon Smirl wrote:
> I just came across a problem with the way the kernel is being
> versioned. The DRM driver needs an IFDEF for the four level page table
> change depending on kernel version built against. I used this:
> #if LINUX_VERSION_CODE < 0x02060a

you might probably use KERNEL_VERSION here which is more convenient:
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,10)

> The problem is that 2.6.10 was released on kernel.org without the four
> level change. But Linus bk which also has version 2.6.10 has the
> change. Is there some way around this problem?

include/linux/version.h is generated by the Makefile. This file do not
come with the source.

-- 
Vincent Hanquez

Re: kernel versions on Linus bk tree

[Vincent Hanquez]

On Sat, Jan 08, 2005 at 07:54:40PM +0100, Vincent Hanquez wrote:
> > The problem is that 2.6.10 was released on kernel.org without the four
> > level change. But Linus bk which also has version 2.6.10 has the
> > change. Is there some way around this problem?
> 
> include/linux/version.h is generated by the Makefile. This file do not
> come with the source.

oops, I misread, just ignore the comment ;)
sorry for the noise.

-- 
Vincent Hanquez

Re: kernel versions on Linus bk tree

[Horst von Brand]

Jon Smirl <jonsmirl@gmail.com> said:
> I just came across a problem with the way the kernel is being
> versioned. The DRM driver needs an IFDEF for the four level page table
> change depending on kernel version built against. I used this:
> #if LINUX_VERSION_CODE < 0x02060a

Wait for 2.6.11 then. It is the price you pay for fooling around with
kernels in between versions.

If you are experimenting, you know what you are working with, so what is
the problem?
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: kernel versions on Linus bk tree

[Pavel Machek]

Hi!

> I just came across a problem with the way the kernel is being
> versioned. The DRM driver needs an IFDEF for the four level page table
> change depending on kernel version built against. I used this:
> #if LINUX_VERSION_CODE < 0x02060a
> 
> The problem is that 2.6.10 was released on kernel.org without the four
> level change. But Linus bk which also has version 2.6.10 has the
> change. Is there some way around this problem?
> 
> One solution would be to bump the version in Linus bk to 2.6.11-rc1 on
> the first check in after 2.6.10 is cut. The general case of this would
> be to always bump the Linus bk version number immediately after
> cutting the released version.

2.6.11-rc1 seems wrong, but marking it 2.6.10-bk0 should do the trick.

								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: kernel versions on Linus bk tree

[Ryan Anderson]

On Sat, Jan 08, 2005 at 01:23:20PM -0500, Jon Smirl wrote:
> One solution would be to bump the version in Linus bk to 2.6.11-rc1 on
> the first check in after 2.6.10 is cut. The general case of this would
> be to always bump the Linus bk version number immediately after
> cutting the released version.
> 
> I've been bitten by this ambiguity before when kernels from Linus BK
> have more code in them than the one from kernel.org and have the same
> version number. Changing the timing of the version bump would lessen
> this problem since kernels complied from Linus bk tend to have a short
> life.

I've got a patch in my local tree that tries to solve this through an
attempt to auto-append -bkXXXXXXXX (where each X is hex-digit of the md5
hash of the top-of-tree BK commit).

It doesn't solve the particular problem that caused you to send this
mail, but I think it solves the "modules from a -BK tree overwrite official releases"
problem that prompted me to code up this patch.

(Sam, Kai, I added you in case you have the time to look at this and
apply it or provide some feedback on my approach.  I have both a shell
script that depends on md5sum, and a Perl script in the patch.)

Signed-Off-By: Ryan Anderson <ryan@michonline.com>

diff -Nru a/Makefile b/Makefile
--- a/Makefile	2004-10-27 04:33:05 -04:00
+++ b/Makefile	2004-10-27 04:33:05 -04:00
@@ -513,6 +513,24 @@
 
 #export	INSTALL_PATH=/boot
 
+# If CONFIG_LOCALVERSION_AUTO is set, we automatically perform some tests
+# and try to determine if the current source tree is a release tree, of any sort,
+# or if is a pure development tree.
+# A 'release tree' is any tree with a BitKeeper TAG associated with it.
+# The primary goal of this is to make it safe for a native BitKeeper user to
+# build a release tree (i.e, 2.6.9) and also to continue developing against the
+# current Linus tree, without having the Linus tree overwrite the 2.6.9 tree 
+# when installed.
+#
+# (In the future, CVS and SVN support will be added as well.)
+
+ifeq ($(CONFIG_LOCALVERSION_AUTO),y)
+	ifeq ($(shell ls -d $(srctree)/BitKeeper 2>/dev/null),$(srctree)/BitKeeper)
+		localversion-bk := $(shell $(srctree)/scripts/setlocalversion.sh $(srctree) $(objtree))
+		LOCALVERSION := $(LOCALVERSION)$(localversion-bk)
+	endif
+endif
+
 #
 # INSTALL_MOD_PATH specifies a prefix to MODLIB for module directory
 # relocations required by build roots.  This is not defined in the
diff -Nru a/init/Kconfig b/init/Kconfig
--- a/init/Kconfig	2004-10-27 04:33:05 -04:00
+++ b/init/Kconfig	2004-10-27 04:33:05 -04:00
@@ -69,6 +69,18 @@
 	  object and source tree, in that order.  Your total string can
 	  be a maximum of 64 characters.
 
+config LOCALVERSION_AUTO
+	bool "Automatically append version information to the version string"
+	default y
+	help
+	  This will try to automatically determine if the current tree is a
+	  release tree by looking for BitKeeper tags that belong to the
+	  current top of tree revision.
+	  A string of the format -BKxxxxxxxx will be added to the
+	  localversion.  The string generated by this will be appended 
+	  after any matching localversion* files, but before the 
+	  value set in CONFIG_LOCALVERSION
+
 config SWAP
 	bool "Support for paging of anonymous memory (swap)"
 	depends on MMU
diff -Nru a/scripts/setlocalversion b/scripts/setlocalversion
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion	2004-10-27 04:33:05 -04:00
@@ -0,0 +1,62 @@
+#!/usr/bin/perl
+# Copyright 2004 - Ryan Anderson <ryan@michonline.com>  GPL v2
+
+use strict;
+use warnings;
+use Digest::MD5;
+require 5.006;
+
+if (@ARGV != 2) {
+	print <<EOT;
+Usage: setlocalversion <srctree> <objtree>
+EOT
+	exit(1);
+}
+
+my $debug = 0;
+
+my ($srctree,$objtree) = @ARGV;
+
+my @LOCALVERSIONS = ();
+
+# BitKeeper Version Checks
+
+# We are going to use the following commands to try and determine if
+# this repository is at a Version boundary (i.e, 2.6.10 vs 2.6.10 + some patches)
+# We currently assume that all meaningful version boundaries are marked by a tag.
+# We don't care what the tag is, just that something exists.
+
+#ryan@mythryan2 ~/dev/linux/local$ T=`bk changes -r+ -k`
+#ryan@mythryan2 ~/dev/linux/local$ bk prs -h -d':TAG:\n' -r$T
+
+sub do_bk_checks {
+	chdir($srctree);
+	my $changeset = `bk changes -r+ -k`;
+	chomp $changeset;
+	my $tag = `bk prs -h -d':TAG:' -r'$changeset'`;
+
+	printf("ChangeSet Key = '%s'\nTAG = '%s'\n", $changeset, $tag) if ($debug > 0);
+
+	if (length($tag) == 0) {
+		# We do not have a tag at the Top of Tree, so we need to generate a localversion file
+		# We'll use the given $changeset as input into this.
+		my $localversion = Digest::MD5::md5_hex($changeset);
+		$localversion = substr($localversion,0,8);
+
+		printf("localversion = '%s'\n",$localversion) if ($debug > 0);
+
+		push @LOCALVERSIONS, "BK" . $localversion;
+
+	}
+}
+
+
+if ( -d "BitKeeper" ) {
+	my $bk = `which bk`;
+	chomp $bk;
+	if (length($bk) != 0) {
+		do_bk_checks();
+	}
+}
+
+printf "-%s\n", join("-",@LOCALVERSIONS) if (scalar @LOCALVERSIONS > 0);
diff -Nru a/scripts/setlocalversion.sh b/scripts/setlocalversion.sh
--- /dev/null	Wed Dec 31 16:00:00 196900
+++ b/scripts/setlocalversion.sh	2004-10-27 04:33:05 -04:00
@@ -0,0 +1,19 @@
+#!/bin/sh
+
+BK=`which bk`
+
+srctree=$1
+objtree=$2
+
+if [ "$BK" == "" ];
+then
+	echo "scripts/setlocalversion.sh: Failed to find BK, not appending a -BK* version" >&2
+	exit 0
+fi
+
+cd $srctree
+changeset=`$BK changes -r+ -k`
+tag=`$BK prs -h -d':TAG:' -r'$changeset'`
+if [ "$tag" == "" ]; then
+	echo -n $changeset | md5sum | awk '{printf "-BK%s",substr($1,1,8)}'
+fi


-- 

Ryan Anderson
  sometimes Pug Majere