This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Use uname not sysctl to get the kernel revision
- From: ebiederm at xmission dot com (Eric W. Biederman)
- To: Ulrich Drepper <drepper at redhat dot com>
- Cc: Arjan van de Ven <arjan at infradead dot org>, "Randy.Dunlap" <rdunlap at xenotime dot net>, akpm at osdl dot org, linux-kernel at vger dot kernel dot org, libc-alpha at sourceware dot org, Andi Kleen <ak at suse dot de>
- Date: Wed, 12 Jul 2006 11:42:47 -0600
- Subject: Re: [PATCH] Use uname not sysctl to get the kernel revision
- References: <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <email@example.com> <firstname.lastname@example.org> <44B5283E.email@example.com>
Ulrich Drepper <firstname.lastname@example.org> writes:
> Eric W. Biederman wrote:
>> But uname is noticeably faster than sysctl and uname is more portable
>> across linux flavors. So updating the glibc pthread code to use
>> uname looks like the right way to implement is_smp_system.
> This is (was?) not the universal through. We used uname at some point
> but then I did some profiling and sysctl turned out to be faster.
I track the code bask as far as I could and back to about 2000 in
pthread.c when the code was introduced it always used sys_sysctl.
> If the reverse is true now I can certainly look into changing this but
> the evidence and ideally has to be there. The simplicity of the uname
> code should mean that it's faster.
The evidence and ideally what has to be there?
> In a year or two I'll remove the test anyway. By then there will likely
> not be any UP kernels on reasonable machines anymore and I can drop all
> the conditional code.
Well there are embedded targets but I guess uclibc takes care of them.
Unless a darn good reason for keeping it is found, sys_sysctl won't be
in the kernel several months from now. And uname is faster by a large
margin than /proc.
Right now because there has been a deprecated note in
"include/linux/sysctl.h" since 2003 people currently feel fine with
letting sys_sysctl code bit rot. I am trying to resolve that
situation most likely by just updating the few stray pieces of user
space that care and then cutting out that chunk of kernel code.