Re: [PATCH 2/2] sysctl: remove sysctl syscall

[ebiederm@xmission.com (Eric W. Biederman)]

Andi Kleen <ak@linux.intel.com> writes:

>  On 10/19/2010 10:22 AM, Amerigo Wang wrote:
>> Remove the obsolete sysctl syscall. It was scheduled
>> to be removed in Sept.
>
>
> I thought at least older glibc was still using it? Did anyone check
> what happens if it sees no sysctl(2)?

At the time the deprecation was written we nearly we were in the late
rc's before anything that cared in practice. glibc has stopped even
providing a sys_sysctl wrapper now.

> I think it's ok to remove the full tables, but keeping
> a wrapper just for the functionality glibc use(s/d) is still a good
> idea.

I think the only problem should be the arm glibc.  I don't know if
it's iopl implementation ever got weened off of this.  I tried
but I didn't have good test machine and submitting patches to
glibc is much more of a pain than kernel patches.

To my knowledge there has never been a version of x86 glibc that
had problems if sys_sysctl returns -ENOSYS, and glibc proper removed
even that dependency almost as soon as sys_sysctl was deprecated.

Last time we discussed this (when I added the compatibility wrapper)
I couldn't even find a version of glibc that used sysctl, and I could
not find a distribution old enough that still had a version of glibc
that used sysctl on x86.

We warn on every sys_sysctl value now even the glibc uses and perhaps I
am blind but I haven't seen any bug reports.  So we should be safe
turning this off.

As far as this goes I would just change the default to off for now.
Keeping the code doesn't have any impact on the core of the kernel any
more, or even any binary impact.  As the int -> long conversion has
shown.  If we can get through a release with the code disabled killing
it the next release makes a lot of sense.

Eric