Deprecate sysctl(2), add sysctl_name

Hi,

I know I am a bit late with this. But I hope it can be done for 2.6.

I want to deprecate the numerical sysctl interface for 2.6. The numerical name space always a bad design and never particularly stable (e.g. most distribution kernels assigned freely new numbers so you cannot really rely on it). There are a lot of duplicated and moved sysctls around now. It's not a stable ABI.

Also near all people just use /proc/sys to change sysctls. The sysctl.h/sysctl.c file were always one of the number one sources of rejections when merging different trees.
I don't see the point in having a hard to maintain numerical name space for this when there is a perfectly good symbolic name space.

This patch deprecates sysctl(2) by adding a printk to it. There is one important user of it - glibc checks kernel.version in the startup code - which is still handled without message. This needs to be still handled, but the hope is that there are no other users of the numerical interface.

With the deprecation it can be hopefully removed for 2.8 except for a small stub to emulate kernel.version for old binaries.

If there are any real others users of the numerical namespace we will soon know, but I consider it unlikely.

The primary interface is /proc/sys now. This was always the most widely used way to change sysctl. However there were some objections that embedded systems don't want to have /proc mounted due to memory usage. To offer them an alternative I added a new sysctl_name(2) system call. It has the same semantics as the existing sysctl(2), except that it takes a string instead of a list of numbers to specify the Unlike /proc sysctl_name has low memory overhead (no dentries, no inodes) etc. Still it likely is only useful for embedded users, everybody else should just use /proc/sys.

I hope in 2.7 the internal implementation can be replaced by something based on ELF segments, so that the central sysctl.c file can go away and declaring sysctls will be finally easy. There already is an replacement for it (include/linux/moduleparam.h), but it seems to be not widely used yet. It unfortunately is a bit bloated, which makes it not nice to use for everything.

I also added an compat interface for 64bit architectures with 32bit emulation.

Please consider adding,

-Andi

@@ -6,16 +6,10 @@
  ****************************************************************
  ****************************************************************
  **
- **  WARNING:  
  **  The values in this file are exported to user space via 
- **  the sysctl() binary interface.  Do *NOT* change the 
- **  numbering of any existing values here, and do not change
- **  any numbers within any one set of values.  If you have
- **  to redefine an existing interface, use a new number for it.
- **  The kernel will then return ENOTDIR to any application using
- **  the old binary interface.
- **
- **  --sct
+ **  the sysctl() binary interface.  However this interface
+ **  is unstable and deprecated and will be removed in the future. 
+ **  For a stable interface use /proc/sys.
  **
  ****************************************************************
  ****************************************************************

@@ -276,8 +276,9 @@
 #define __NR_statfs64		268
 #define __NR_fstatfs64		269
 #define __NR_tgkill		270
+#define __NR_sysctl_name	271
 
-#define NR_syscalls 271
+#define NR_syscalls 272
 
 /* user-visible error numbers are in the range -1 - -124: see <asm-i386/errno.h> */
 

@@ -877,5 +877,6 @@
 	.long sys_statfs64
 	.long sys_fstatfs64	
 	.long sys_tgkill
- 
+	.long sys_sysctl_name
+	
 nr_syscalls=(.-sys_call_table)/4

I'd prefer to first _only_ deprecate it, and if somebody really really decides that they want another interface than /proc too, we can re-visit the thing then.

I doubt there is any real reason to not just use the /proc interface, and I dislike pre-emptive engineering.

Linus

Agreed.

Further, as someone working on embedded, I think requiring /proc is fine for this.

Robert Love

Ok fine for me. Here is a new patch that only deprecates.

I don't feel particularly strongly about the sysctl_name thing, if you think it's not necessary great.

-Andi

-------------

Deprecate numerical sysctl namespace. The only exception is kernel/version, which is widely used in glibc. The new recommended interface is /proc/sys

@@ -6,16 +6,10 @@
  ****************************************************************
  ****************************************************************
  **
- **  WARNING:  
  **  The values in this file are exported to user space via 
- **  the sysctl() binary interface.  Do *NOT* change the 
- **  numbering of any existing values here, and do not change
- **  any numbers within any one set of values.  If you have
- **  to redefine an existing interface, use a new number for it.
- **  The kernel will then return ENOTDIR to any application using
- **  the old binary interface.
- **
- **  --sct
+ **  the sysctl() binary interface.  However this interface
+ **  is unstable and deprecated and will be removed in the future. 
+ **  For a stable interface use /proc/sys.
  **
  ****************************************************************
  ****************************************************************

@@ -823,7 +838,16 @@
 
 	if (copy_from_user(&tmp, args, sizeof(tmp)))
 		return -EFAULT;
-		
+	
+	if (tmp.nlen != 2 || tmp.name[0] != CTL_KERN ||
+	    tmp.name[1] != KERN_VERSION) { 
+		int i;
+		printk(KERN_INFO "%s: numerical sysctl ", current->comm); 
+		for (i = 0; i < tmp.nlen; i++) 
+			printk("%d ", tmp.name[i]); 
+		printk("is obsolete.\n");
+	} 
+
 	lock_kernel();
 	error = do_sysctl(tmp.name, tmp.nlen, tmp.oldval, tmp.oldlenp,
 			  tmp.newval, tmp.newlen);

Only on demand. The only reasonable way would be to limit it per process (print it once)
but before doing that I would like to see if that's even needed.

Also I doubt sysctls are that commonly called if they are even used.

-Andi

It looks like kudzu (also known as "the RH hardware hack from h*ll") actually messes with "sysctl 1 23", aka "/proc/sys/kernel/printk".

Why it thinks it should mess with it I don't know. I dislike how the distributions tend to shut off kernel messages that can tell you when something is seriously wrong, making the error cases be silent hangs instead of having some indication of why something went wrong.. I wonder if that's what kudzu is doing - shutting the kernel up before it starts doing things that it should never do.

Anyway, having one

kudzu: numerical sysctl 1 23 is obsolete.

during bootup seems to be a fairly non-irritating thing, and hopefully the kudzu people can just stop doing whatever they are doing.

Linus