Re: how to detect a debian kernel from `uname -r`
On Sun, Sep 11, 2005 at 06:01:26PM +0200, Andrea Arcangeli wrote:
> 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)
Nope,; it works for debian packages. But you can match that to kernels.
> > > 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.
Because debian flavours are not unique among all arches, so ...
> 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?
Well, if you search for a debian kernel, you can get the uname -r output, and
then match it again all the flavours, but it is easier to match them on a per
arch basis, especially as it might be that two flavours on two different
arches share the same name. Not sure if this is the case right now.
> > 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 will let others comment, i think.
> I'd rather keep it separated from /proc/version but that's just an
> implementation detail.
but it would be the lest obnoxious way of doing this.
> > 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.
All files outside of /usr/local and /home/<user> are per policy to be left to
the package manager. Even if some do not follow policy, and unpack linux
kernel trees in /usr/src, i can guarantee you that they will not mess with the
/usr/src/path subrdir provided by the debian-patch packages.
> > > 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, possibly, but i have some doubt of the values of it. Actually, there is
a sure way of doing this, you could simply get a database of all the ubuntu or
debian kernels out there (they are all archived), and then simply match their
md5sum against the md5sum of the installed kernel (which is
/boot/vmlinu[zx]-`uname -r`). That way, you have no doubts ay all :)
> > 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 ;).
Assume debian by default :) I am not sure, but i guess ubuntu and debian use
another set of flavours even, but if you really want to do it right, the most
sure way is the md5sum database.
Friendly,
Sven Luther
Reply to: