Re: how to detect a debian kernel from `uname -r`
On Sat, Sep 10, 2005 at 07:43:31AM +0200, Sven Luther wrote:
> Not a good idea. Why clutter the namespace of versions in order to adapt to
> non-debian needs. ? What is it you intent to do anyway ?
My intent is to be able to tell the "branch" of the kernel based on
`uname -r` (per subject). So if I see 2.6.13-whatever-debian it means it
was a kernel patches by the debian patchset. If I see 2.6.16-3-ppc64
I don't know for sure where it comes from.
-mm adds -mm, -ck adds -ck, ac adds ac, fedora adds FC, RT adds -rt,
basically anybody who makes substantial changes is already doing the
thing you call "cluttering the namespace".
So it doesn't sound such a terrible thing from my point of view.
I don't see what's the bad thing about marking -debian or -deb the
kernels that you _modify_ with your set of patches.
I'm not saying that you have to add -deb if you _don't_ modify the
kernel source, infact I believe you shouldn't add -deb unless you change
the kernel source.
But if you apply your own patches (like -mm,-ck,-ac,FC,EL,etc..etc..)
then what's wrong at being able to identify which patchset was applied
like it's already possible for many other branches?
> more /proc/version
> Linux version 2.6.12-1-powerpc (waldi@trick) (gcc version 4.0.2 20050806
> (prerelease) (Debian 4.0.1-4)) #1 Tue Aug 16 20:08:54 UTC 2005
That's the compiler, I'm not tracking the compiler. In theory I could,
but then it would get wrong if I would grab a debian kernel and compile
it under suse. However if I fail to idenfiy the branch of the kernels
based on `uname -r`, I agree the fallback would be to use the compiler
to identify the branch (even if it's not completely reliable).
Personally I also see as pointless to add 686 or k7 in the name, why
don't you simply enable /proc/config.gz that will tell the user a _lot_
more than just the cpu compilation selection? But that's quite offtopic,
my intent was only to try to identify the kernel vendor/branches.
Thanks.
Reply to: