Andi Kleen <ak@xxxxxxxxxxxxxxx> writes: >> 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. > > What matters are old glibc installations, not new ones. No. It matters a lot that glibc has stopped providing the wrapper, as that makes it doubly difficult for new users to start using the binary sysctl interface. >>> 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. > > > Eric, I think you have the wrong approach here: it doesn't matter what new glibc > does, > but what any old glibcs do. If any old one uses it we cannot simply > remove it. ???? If there are any current users we can not remove it. If current glibc on arm still uses this (which I expect it does) we can not possibly remove the code. With a current user it doesn't matter what historical versions of glibc do. >> 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. >> > > AFAIK older glibc didn't use some functionality in the kernel if they couldn't > figure out the right kernel version. And they were using sysctl for > this. Sigh. We have had the conversation a dozen times. I have looked and reasearched until I am bored. It was the pthreads code attempting to detect if we are smp. At worst the code would not optimize for the uniprocessor case. But again that was long ago, and last time we had this conversation it was impossible for me to find glibc binaries on x86 that were still even trying to do this. We have been warning on even the historical glibc pthreads usage for over a year now. >> 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. > > When I did my really old work for sysctl_binary() I ran into this problem. > All glibc binaries on my distribution back then used sysctl. Yep. Which was what 4+ years ago? Perhaps the question should be in practice does any enterprise distro have a glibc that uses sys_sysctl. Not that I think even that case is particularly interesting. >> 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. >> > > I don't so. I don't think we can that easily break compatibility, sorry. > Binary compatibility is something very important for Linux. Duh! Which is why we have the code. Of course the safe course is to keep the code and disable the feature, if no one is using it. > Anyways I'm fine with removing the bulk of the tables, but not the compat > table for the one glibc uses. Removing the bulk of the tables is another name for breaking binary compatibility. Which you said is a no no. We have the code and it works at this point, there is no point to neutering it. Especially when distros whose glibc pthread code used this are for the most part lost in the course of history. To the best of my knowledge the last and user of sys_sysctl is the glibc ioperm (my apologies I mispoke when I said iopl) implementation on arm. Not that people run around calling ioperm very often in any distro. All of that said I think disabling sys_sysctl by default now is totally reasonable. If there is a percentage in removing the code we can worry about that later. Perhaps we should add a CONFIG_CRUFT and move sys_sysctl under there. Binary compatibility that nothing needs but that we actually have code for just in case. 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