Re: how to detect a debian kernel from `uname -r`
On Sun, Sep 11, 2005 at 07:35:02AM +0200, Sven Luther wrote:
> and report data ? If so, you may look into the popularity context package ?
Does that work for all distro out there? Could you post the url of
the equivalent of a klive.cpushare.com chart so we can compare? (google
pointed me to the package, not to the chart)
> > If you can improve this regexp (which seems the way to go for now)
> > you're very welcome:
> >
> > 'Debian' : re.compile(r'^(\d+)\.(\d+)\.(\d+)(?:-git(\d+)|\.(\d+)|-rc(\d+))?-(\d+)-(?:[3456]86|k7|generic|amd64-k8)')
> >
> > Right now I only added the basics to catch the most frequent archs in
> > klive unknown listing, it's true I can't catch all 12 archs if somebody
> > would be running klive on top of them.
>
> Well, i guess i would not do it like you do ? Why have only a single regext,
> instead of a case switch for example, or better yet two case switches, one
> matching uname -m, and then going for uname -r.
Why should I go for uname first? I want all archs to fit in the single
uname -r. If you click on 2.6.13 it will show internally all different
archs.
If you're interested in a single arch just click the filter at the top,
click on x86-64 and you'll see the stats only for x86-64 (see NR going
down etc..).
Why should I care about uname -m, when I've the filter at the top?
> I still think you are taking the wrong approach here, maybe you shouild
> propose a speacial patch, which each distribution could apply and fill a data
> with distribution info, and which would then appear in /proc/version, and not
> try to get distributions to polute the version namespace.
That is a fine solution too. I proposed to "polute the version
namespace" first because that sounded the right thing to do to me,
despite you didn't like it.
I'd rather keep it separated from /proc/version but that's just an
implementation detail.
> Notice also, that on a debian system, you may find the exact sert of patches
> applied in : /usr/src/patches :)
Sorry but I'd rather not depend on people not messing /usr/src and more
important I'd rather avoid distro dependent details.
> > Since the ubuntu kernel seems to be very different from debian kernel, I
> > wonder how I can detect it with uname -r, I guess I can't right now.
>
> Like said, wrong approach.
Keep in mind this was written for the mainline kernels running on all
sort of userland (where most people normally don't mess with
localversion before compiling), what you see online (i.e. probably
mixing ubuntu and debian) seems the best thing I can do right now.
> Well, i even doubt it will work well for mainline, since people can and will
> modify the version to suite them best, or apply a random set of patches.
well, as a matter of fact it works pretty well already, count the number
of mainline entries compared to the number of unknown entries. It's
possible somebody patched the kernel, but it doesn't need to be perfect,
and even if they patched the kernel, they're still testing the 2.6.13
codebase so it's not that bad (just like what Andres said about debian,
that you don't apply many patches, so ideally you could be accounted
like mainline kernels, but for ubuntu this is not the case and currently
I can't even detect the difference between ubuntu and Debian ;).
Reply to: