Andi Kleen <ak@xxxxxxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-doc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
