Kernel versioning [was Re: Kernel package and modules]
mwester at dls.net
Tue Aug 5 17:48:26 CEST 2008
Andy Green wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> 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
*sigh* Well, I tried. Perhaps I'm not the convincing orator
(emailator?) that is required to present the customer-support POV.
Further, it's unclear to whom the argument needs to be presented.
I'll figure out some means -- despite your unilateral decision -- to
ensure that the average joe-geek who bought the phone can flash an
experimental kernel and test it with ease, low-risk, and as small an
effort as possible. It'll just have to be another community effort.
More information about the devel