Re: [PATCH] Use uname not sysctl to get the kernel revision

[Andi Kleen]

On Thursday 13 July 2006 01:24, Theodore Tso wrote:

> Um, if glibc is using sys_sysctl, then that's a pretty good reason.
> Once we remove it from the kernel, then people will be forced to
> upgrade glibc's before they can install a newer kernel.  Can we please
> give people some time for an version of glibc with this change to make
> it out to most deployed systems, first?  It's really annoying when
> it's not possible to install a stock kernel.org kernel on a system,
> and often upgrading glibc is not a trivial thing to do on a
> distribution userspace, especially if there is a concern for ISV
> compatibility.  (Especially if C++ code is involved, unfortunately.)

glibc still works, just slower. But I think the best strategy 
is just to emulate the single sysctl glibc is using and printk
for the rest.

> What we should do is what we've done in the past before removing a
> system call like this.  printk a deprecation warning no more than n
> times an hours with the process name using the deprecated interface.

We did this some time ago, but Andrew took it out (partly because
the original code was somewhat broken and the printk tended to trigger
too often in crashme) 

Hopefully he puts it back in now.

> P.S.  I happen to be one those developers who think the binary
> interface is not so bad, and for compared to reading from /proc/sys,
> the sysctl syscall *is* faster.  But at the same there, there really
> isn't anything where really does require that kind of speed, so that
> point is moot.  But at the same time, what is the cost of leaving
> sys_sysctl in the kernel for an extra 6-12 months, or even longer,
> starting from now?  

The numerical namespace for sysctl is unsalvagable imho. e.g. distributions
regularly break it because there is no central repository of numbers
so it's not very usable anyways in practice.
 
-Andi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/