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

[Theodore Tso <tytso@mit.edu>]

On Wed, Jul 12, 2006 at 11:42:47AM -0600, Eric W. Biederman wrote:
> 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.

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.)

> 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.

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.
A deprecated note in a header isn't necessarily something which will
be noticed by userspace programmers.  Heck, it isn't even in
Documentation/feature-removal-schedule.txt yet.

If people want to remove it, let's please do this in an orderly
fashion, and with ample warning that people besides kernel developers
will actually *notice*.

						- Ted

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?  

Or if we going to remove parts of sysctl, can we at least keep enough
there so that existing glibc systems don't break?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/