Cong Wang <amwang@xxxxxxxxxx> writes: > On 10/20/10 00:00, Eric W. Biederman wrote: >> 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. > > > I saw that in Changelog of glibc too, but that was back to 2000, 10 years > past, I don't see any code using sysctl() in glibc now, except sys_sysctl() > itself, of course. You have to look in the glibc-ports tree to see the arm code. The arm support is not in the main glibc tree for some reason. Hmm. Looking I thought sys_sysctl had stopped being exported from glibc but it appears I was wrong. >> 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. > > But you put sysctl in features-removal-schedule.txt 3 years ago. :) I did and before that the first version of the sysctl man page said the binary values were not portable between kernels, so don't use the system call. > I believe they should see the kernel warnings if they are still using > sysctl. Unfortunately sometimes a word to the wise isn't quite enough. Sigh. I very much think having the sysctl code disabled by default is definitely safe right now, and the first responsible step in getting this code removed from the kernel. There were two original reasons for the deprecations. Maintaining the binary sysctl logic was bug prone, and no one was using sysctl. The rewriting of the binary interface into binary_sysctl.c takes care of most if not all of the maintenance concerns. You may think you are using the binary interface but the kernel just rewrites it into a /proc access. What is left is an interface in the kernel that no one uses and that will eventually bit rot, for lack of care, attention, and testing, but we still have a while until that happens. I recommend this: --- diff --git a/init/Kconfig b/init/Kconfig index 2de5b1c..a9e1cda 100644 --- a/init/Kconfig +++ b/init/Kconfig @@ -808,7 +808,7 @@ config UID16 config SYSCTL_SYSCALL bool "Sysctl syscall support" if EMBEDDED depends on PROC_SYSCTL - default y + default n select SYSCTL ---help--- sys_sysctl uses binary paths that have been found challenging @@ -816,11 +816,15 @@ config SYSCTL_SYSCALL using paths with ascii names is now the primary path to this information. - Almost nothing using the binary sysctl interface so if you are - trying to save some space it is probably safe to disable this, - making your kernel marginally smaller. + This option is kept as a service to our loyal customers who + have ignored all of our warnings over the years and have a + binary somewhere that won't work without this. + + This code is not regularly used or tested and will probably have + bit-rotted before someone cares enough to do more maintenance on it + so enable at your own risk. - If unsure say Y here. + Say N here. config KALLSYMS bool "Load all symbols for debugging/ksymoops" if EMBEDDED -- 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
