* kernel versions on Linus bk tree
@ 2005-01-08 18:23 Jon Smirl
2005-01-08 18:54 ` Vincent Hanquez
` (3 more replies)
0 siblings, 4 replies; 6+ messages in thread
From: Jon Smirl @ 2005-01-08 18:23 UTC (permalink / raw)
To: lkml
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
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: kernel versions on Linus bk tree 2005-01-08 18:23 kernel versions on Linus bk tree Jon Smirl @ 2005-01-08 18:54 ` Vincent Hanquez 2005-01-08 19:00 ` Vincent Hanquez 2005-01-09 3:44 ` Horst von Brand ` (2 subsequent siblings) 3 siblings, 1 reply; 6+ messages in thread From: Vincent Hanquez @ 2005-01-08 18:54 UTC (permalink / raw) To: Jon Smirl; +Cc: lkml 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel versions on Linus bk tree 2005-01-08 18:54 ` Vincent Hanquez @ 2005-01-08 19:00 ` Vincent Hanquez 0 siblings, 0 replies; 6+ messages in thread From: Vincent Hanquez @ 2005-01-08 19:00 UTC (permalink / raw) To: Jon Smirl; +Cc: lkml 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel versions on Linus bk tree 2005-01-08 18:23 kernel versions on Linus bk tree Jon Smirl 2005-01-08 18:54 ` Vincent Hanquez @ 2005-01-09 3:44 ` Horst von Brand 2005-01-10 22:26 ` Pavel Machek 2005-01-10 23:55 ` Ryan Anderson 3 siblings, 0 replies; 6+ messages in thread From: Horst von Brand @ 2005-01-09 3:44 UTC (permalink / raw) To: Jon Smirl; +Cc: lkml 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel versions on Linus bk tree 2005-01-08 18:23 kernel versions on Linus bk tree Jon Smirl 2005-01-08 18:54 ` Vincent Hanquez 2005-01-09 3:44 ` Horst von Brand @ 2005-01-10 22:26 ` Pavel Machek 2005-01-10 23:55 ` Ryan Anderson 3 siblings, 0 replies; 6+ messages in thread From: Pavel Machek @ 2005-01-10 22:26 UTC (permalink / raw) To: Jon Smirl; +Cc: lkml 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! ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: kernel versions on Linus bk tree 2005-01-08 18:23 kernel versions on Linus bk tree Jon Smirl ` (2 preceding siblings ...) 2005-01-10 22:26 ` Pavel Machek @ 2005-01-10 23:55 ` Ryan Anderson 3 siblings, 0 replies; 6+ messages in thread From: Ryan Anderson @ 2005-01-10 23:55 UTC (permalink / raw) To: Jon Smirl; +Cc: lkml, kai, sam 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2005-01-11 0:10 UTC | newest] Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2005-01-08 18:23 kernel versions on Linus bk tree Jon Smirl 2005-01-08 18:54 ` Vincent Hanquez 2005-01-08 19:00 ` Vincent Hanquez 2005-01-09 3:44 ` Horst von Brand 2005-01-10 22:26 ` Pavel Machek 2005-01-10 23:55 ` Ryan Anderson
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).