Kernel versioning [was Re: Kernel package and modules]

Andy Green andy at
Tue Aug 5 16:32:21 CEST 2008

Hash: SHA1

Somebody in the thread at some point said:

Just to fill folks in, I patched my build script to add the branch name
and git head hash to the "version" the kernel reports.

# uname -a
Linux fic-gta02 2.6.26-andy-2.6.26:bf9b3bb99b5b8708-mokodev #1001
PREEMPT Tue Aug 5 11:47:55 BST 2008 armv4tl GNU/Linux

Mike's focus here comes down to /lib/module/... path that is searched,
it changes every build the way I did it.  I think that's a good thing
and he likes to see the old modules.

| And the argument that I could go check the git hash thingy in the
| existing rootfs, edit the kernel Makefile to match, and build that is
| also just way too much work to make it likely that I or many others
| would actually bother.

I think I'm getting your POV.  But, what you are doing is making the dev
remember to crank up EXTRAVERSION by hand dependent on what code is
writing and what patches he has added to his tree.  You mention lazy but
on top of that people are highly distracted when they work on stuff,
especially stuff that isn't playing ball.  This seems unworkable and
error prone to me.  Autochanging EXTRAVERSION otoh will never give
trouble from this direction.

If you are developing, you have a choice to do it by packages, which is
the "proper" way (I don't do that either because the packaging system
frightens me), or run with "low modules" or "no modules" config.  That
way, you can blow your kernel into your rootfs or kernel partition and
reboot without worrying about modules.  And, with the EXTRAVERSION
method, you won't pick up the wrong modules either later in rootfs.

| The git hash, as proposed, is a horrible little thing that should be
| there, but not in EXTRAVERSION.  The EXTRAVERSION should be changed as I
| describe above, by humans, because we need for as many people as
| possible to be able to test kernels and kernel-patches, and with the
| current change rate the very last thing we should be considering is
| making it harder for people to help out in the testing effort.

I think I understand your meaning but I didn't find any great agreement
in by heart about it.  I still prefer the certainty of sticking the git
HEAD hash in EXTRAVERSION (which turns up in the /lib/module/... path
searched) so we never worry about introducing subtle misbehaviours from
wrong module set.

- -Andy
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora -


More information about the devel mailing list