config SYSCTL_SYSCALL

config SYSCTL_SYSCALL

[Jan Beulich]

What is the purpose of

config SYSCTL_SYSCALL
	bool "Sysctl syscall support" if EMBEDDED
	default n

Allowing only embedded to turn this *on* ? Normally, you want
embedded to have more freedom in turning stuff off, so this
looks odd to me (and on one of my older boxes I definitely have
at least one OS-provided tool that uses this syscall, so I'd like
to be able to turn it on.

Thanks for an explanation,
Jan

Re: config SYSCTL_SYSCALL

[Randy Dunlap]

On Tue, 17 Oct 2006 16:59:10 +0100 Jan Beulich wrote:

> What is the purpose of
> 
> config SYSCTL_SYSCALL
> 	bool "Sysctl syscall support" if EMBEDDED
> 	default n
> 
> Allowing only embedded to turn this *on* ? Normally, you want
> embedded to have more freedom in turning stuff off, so this
> looks odd to me (and on one of my older boxes I definitely have
> at least one OS-provided tool that uses this syscall, so I'd like
> to be able to turn it on.

You can't enable it (after enabling EMBEDDED)?

Feel free to send a patch to remove /if EMBEDDED/
and move the Kconfig entry up above all of the EMBEDDED options.

---
~Randy

[PATCH] Restore sysctl syscall option for non-embedded users

[Cal Peake]

On Tue, 17 Oct 2006, Randy Dunlap wrote:

> On Tue, 17 Oct 2006 16:59:10 +0100 Jan Beulich wrote:
> 
> > What is the purpose of
> > 
> > config SYSCTL_SYSCALL
> > 	bool "Sysctl syscall support" if EMBEDDED
> > 	default n
> > 
> > Allowing only embedded to turn this *on* ? Normally, you want
> > embedded to have more freedom in turning stuff off, so this
> > looks odd to me (and on one of my older boxes I definitely have
> > at least one OS-provided tool that uses this syscall, so I'd like
> > to be able to turn it on.
> 
> You can't enable it (after enabling EMBEDDED)?
> 
> Feel free to send a patch to remove /if EMBEDDED/
> and move the Kconfig entry up above all of the EMBEDDED options.

My dmesg gets spammed to all hell with these warnings. Can we keep this 
option easily visible till it gets ripped out Jan of 2007 (see 
Documentation/feature-removal-schedule.txt for reference)?

From: Cal Peake <cp@absolutedigital.net>

Restore the deprecated sysctl system call option for non-embedded users 
and mark it clearly deprecated.

Signed-off-by: Cal Peake <cp@absolutedigital.net>

--- ./init/Kconfig~orig	2006-10-17 13:52:05.000000000 -0400
+++ ./init/Kconfig	2006-10-17 13:58:25.000000000 -0400
@@ -286,24 +286,8 @@ config TASK_XACCT
 config SYSCTL
 	bool
 
-menuconfig EMBEDDED
-	bool "Configure standard kernel features (for small systems)"
-	help
-	  This option allows certain base kernel options and settings
-          to be disabled or tweaked. This is for specialized
-          environments which can tolerate a "non-standard" kernel.
-          Only use this if you really know what you are doing.
-
-config UID16
-	bool "Enable 16-bit UID system calls" if EMBEDDED
-	depends on ARM || CRIS || FRV || H8300 || X86_32 || M68K || (S390 && !64BIT) || SUPERH || SPARC32 || (SPARC64 && SPARC32_COMPAT) || UML || (X86_64 && IA32_EMULATION)
-	default y
-	help
-	  This enables the legacy 16-bit UID syscall wrappers.
-
 config SYSCTL_SYSCALL
-	bool "Sysctl syscall support" if EMBEDDED
-	default n
+	bool "Sysctl syscall support (DEPRECATED)"
 	select SYSCTL
 	---help---
 	  Enable the deprecated sysctl system call.  sys_sysctl uses
@@ -318,6 +302,21 @@ config SYSCTL_SYSCALL
 	  Unless you have an application that uses the sys_sysctl interface
  	  you should probably say N here.
 
+menuconfig EMBEDDED
+	bool "Configure standard kernel features (for small systems)"
+	help
+	  This option allows certain base kernel options and settings
+          to be disabled or tweaked. This is for specialized
+          environments which can tolerate a "non-standard" kernel.
+          Only use this if you really know what you are doing.
+
+config UID16
+	bool "Enable 16-bit UID system calls" if EMBEDDED
+	depends on ARM || CRIS || FRV || H8300 || X86_32 || M68K || (S390 && !64BIT) || SUPERH || SPARC32 || (SPARC64 && SPARC32_COMPAT) || UML || (X86_64 && IA32_EMULATION)
+	default y
+	help
+	  This enables the legacy 16-bit UID syscall wrappers.
+
 config KALLSYMS
 	 bool "Load all symbols for debugging/kksymoops" if EMBEDDED
 	 default y

Re: [PATCH] Restore sysctl syscall option for non-embedded users

[Alan Cox]

Ar Maw, 2006-10-17 am 14:17 -0400, ysgrifennodd Cal Peake:
> My dmesg gets spammed to all hell with these warnings. Can we keep this 
> option easily visible till it gets ripped out Jan of 2007 (see 
> Documentation/feature-removal-schedule.txt for reference)?

NAK

The problem is that this option is available at all. Deprecating
syscalls especially trivial ones is fundamentally wrong. The correct fix
is to make sysctl always present except as an option for embedded and
not to deprecate it.

Re: [PATCH] Restore sysctl syscall option for non-embedded users

[Cal Peake]

On Tue, 17 Oct 2006, Alan Cox wrote:

> Ar Maw, 2006-10-17 am 14:17 -0400, ysgrifennodd Cal Peake:
> > My dmesg gets spammed to all hell with these warnings. Can we keep this 
> > option easily visible till it gets ripped out Jan of 2007 (see 
> > Documentation/feature-removal-schedule.txt for reference)?
> 
> NAK
> 
> The problem is that this option is available at all. Deprecating
> syscalls especially trivial ones is fundamentally wrong. The correct fix
> is to make sysctl always present except as an option for embedded and
> not to deprecate it.

Works for me. If everyone agrees I'll whip up a patch to match Alan's 
description and remove the deprecation notice.

thanks,

  - C.

-- 
"There is nothing wrong with your television set. Do not attempt
    to adjust the picture. We are controlling transmission."
                    -- The Outer Limits

Re: [PATCH] Restore sysctl syscall option for non-embedded users

[Andrew Morton]

On Tue, 17 Oct 2006 23:11:36 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Ar Maw, 2006-10-17 am 14:17 -0400, ysgrifennodd Cal Peake:
> > My dmesg gets spammed to all hell with these warnings. Can we keep this 
> > option easily visible till it gets ripped out Jan of 2007 (see 
> > Documentation/feature-removal-schedule.txt for reference)?
> 
> NAK
> 
> The problem is that this option is available at all. Deprecating
> syscalls especially trivial ones is fundamentally wrong. The correct fix
> is to make sysctl always present except as an option for embedded and
> not to deprecate it.

yes, it appears that we screwed that up, but I haven't got around to thinking about
it yet.

It does appear that so many things are using sys_sysctl() that any plan to
remove it completely is over-optimistic.

[PATCH] Undeprecate the sysctl system call

[Cal Peake]

On Tue, 17 Oct 2006, Andrew Morton wrote:

> yes, it appears that we screwed that up, but I haven't got around to thinking about
> it yet.

Well, here's a patch that hopefully solves the mess :)

From: Cal Peake <cp@absolutedigital.net>

Undeprecate the sysctl system call and default to always include it with 
the option for embedded folks to exclude it. Also, remove it's entry from 
the feature removal file.

Signed-off-by: Cal Peake <cp@absolutedigital.net>

--- ./init/Kconfig~orig	2006-10-17 17:54:09.000000000 -0400
+++ ./init/Kconfig	2006-10-17 18:49:36.000000000 -0400
@@ -303,20 +303,20 @@ config UID16
 
 config SYSCTL_SYSCALL
 	bool "Sysctl syscall support" if EMBEDDED
-	default n
+	default y
 	select SYSCTL
 	---help---
-	  Enable the deprecated sysctl system call.  sys_sysctl uses
-	  binary paths that have been found to be a major pain to maintain
-	  and use.  The interface in /proc/sys is now the primary and what
-	  everyone uses.
-
-	  Nothing has been using the binary sysctl interface for some
-	  time now so nothing should break if you disable sysctl syscall
-	  support, and your kernel will get marginally smaller.
+	  This option allows you to specify whether or not to build into
+	  your kernel support for the sysctl system call.  You can disable
+	  this if you are building a kernel for a system with limited
+	  resources (e.g. an embedded device) and your kernel image will
+	  shrink by a few kilobytes.
+
+	  NOTE: Disabling this option will cause a warning to be printed
+	        if a program attempts to use this system call.
 
-	  Unless you have an application that uses the sys_sysctl interface
- 	  you should probably say N here.
+	  If you are sure your userspace enviroment has no need for this
+	  system call you can say N here.
 
 config KALLSYMS
 	 bool "Load all symbols for debugging/kksymoops" if EMBEDDED
--- ./Documentation/feature-removal-schedule.txt~orig	2006-10-17 17:54:04.000000000 -0400
+++ ./Documentation/feature-removal-schedule.txt	2006-10-17 18:10:35.000000000 -0400
@@ -53,18 +53,6 @@ Who:	Mauro Carvalho Chehab <mchehab@brtu
 
 ---------------------------
 
-What:	sys_sysctl
-When:	January 2007
-Why:	The same information is available through /proc/sys and that is the
-	interface user space prefers to use. And there do not appear to be
-	any existing user in user space of sys_sysctl.  The additional
-	maintenance overhead of keeping a set of binary names gets
-	in the way of doing a good job of maintaining this interface.
-
-Who:	Eric Biederman <ebiederm@xmission.com>
-
----------------------------
-
 What:	PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
 When:	November 2005
 Files:	drivers/pcmcia/: pcmcia_ioctl.c

Re: [PATCH] Undeprecate the sysctl system call

[Alan Cox]

Ar Maw, 2006-10-17 am 19:09 -0400, ysgrifennodd Cal Peake:
> On Tue, 17 Oct 2006, Andrew Morton wrote:
> 
> > yes, it appears that we screwed that up, but I haven't got around to thinking about
> > it yet.
> 
> Well, here's a patch that hopefully solves the mess :)
> 
> From: Cal Peake <cp@absolutedigital.net>

Acked-by: Alan Cox <alan@redhat.com>

sysctl() should probably be described as obsolete in the manual pages
for sysctl(2) but it doesn't want pulling out of the kernel.

Alan

Re: [PATCH] Undeprecate the sysctl system call

[Eric W. Biederman]

Cal Peake <cp@absolutedigital.net> writes:

> On Tue, 17 Oct 2006, Andrew Morton wrote:
>
>> yes, it appears that we screwed that up, but I haven't got around to thinking
> about
>> it yet.
>
> Well, here's a patch that hopefully solves the mess :)
>
> From: Cal Peake <cp@absolutedigital.net>
>
> Undeprecate the sysctl system call and default to always include it with 
> the option for embedded folks to exclude it. Also, remove it's entry from 
> the feature removal file.
>
> Signed-off-by: Cal Peake <cp@absolutedigital.net>

NAK on the grounds that it does not fix the related wording in sysctl.h

As for the rest of this I disagree with this direction as it is not
fixing the status quo, just attempting to maintain it.

The status quo is that there is one ridiculous user in glibc that
doesn't break when sys_sysctl is not compiled in.

The status quo is that we don't properly maintain sysctl.h and we arbitrarily
change the numbers.

The status quo is that sys_sysctl has been deprecated for longer than
feature-removal.txt

If we choose to maintain this and step up to maintaining the binary
ABI which no one uses then I am happy.

If we agree to remove the useless thing I am also happy.

It is wrong to maintain the status quo.  Who is volunteering to step
up to the plate and maintain this thing?

I have just about enough time and energy to finish killing sys_sysctl.


Contrary to Alan's assertion all of those binary numbers in sysctl.h
are not trivial to maintain or we would not have broken the ABI
several times in the 2.6 series.  Although I do agree it should be
simple (not trivial) to maintain if we decide it is important.

Eric

Re: [PATCH] Undeprecate the sysctl system call

[Alan Cox]

Ar Maw, 2006-10-17 am 21:41 -0600, ysgrifennodd Eric W. Biederman:
> > Signed-off-by: Cal Peake <cp@absolutedigital.net>
> 
> NAK on the grounds that it does not fix the related wording in sysctl.h

Just post a patch to fix the wording

> As for the rest of this I disagree with this direction as it is not
> fixing the status quo, just attempting to maintain it.

Good. That is how you manage system call interfaces.

> The status quo is that we don't properly maintain sysctl.h and we arbitrarily
> change the numbers.

Not the core basic ones that are those people care about

> It is wrong to maintain the status quo.  Who is volunteering to step
> up to the plate and maintain this thing?

For the existing values as is that matter anyone can do it, because it
just means not making a change.

Its very simple: sysctl was a neat BSD syscall that turned out to be
less ideal than using the fs for it. We added it, we supported it, we
get to keep it. We just stick notes in the docs saying "please use /proc
instead".

Alan

Re: [PATCH] Undeprecate the sysctl system call

[Andi Kleen]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> 
> Its very simple: sysctl was a neat BSD syscall that turned out to be
> less ideal than using the fs for it. We added it, we supported it, we
> get to keep it. We just stick notes in the docs saying "please use /proc
> instead".

You call that numerical name space neat?  IMHO it was a totally bogus
idea. There is already a perfectly fine file system name space, why
add another one?

Anyways, imho the right solution is to remove the numerical
sysctl infrastructure (including most of sysctl.h), but keep
sys_sysctl() with a small mapping table that maps the few
numerical sysctls (mostly KERN_VERSION) that are actually used to 
path names internally. The rest should be ENOSYS.

-Andi

Re: [PATCH] Undeprecate the sysctl system call

[Alan Cox]

Ar Mer, 2006-10-18 am 13:33 +0200, ysgrifennodd Andi Kleen:
> You call that numerical name space neat?  IMHO it was a totally bogus
> idea. There is already a perfectly fine file system name space, why
> add another one?

The sysctl number space came first and when it appeared it was neat

> Anyways, imho the right solution is to remove the numerical
> sysctl infrastructure (including most of sysctl.h), but keep
> sys_sysctl() with a small mapping table that maps the few
> numerical sysctls (mostly KERN_VERSION) that are actually used to 
> path names internally. The rest should be ENOSYS.

More work for less compatibility, that doesn't sound very clever.

Alan

Re: [PATCH] Undeprecate the sysctl system call

[Andi Kleen]

On Wednesday 18 October 2006 14:15, Alan Cox wrote:

> > Anyways, imho the right solution is to remove the numerical
> > sysctl infrastructure (including most of sysctl.h), but keep
> > sys_sysctl() with a small mapping table that maps the few
> > numerical sysctls (mostly KERN_VERSION) that are actually used to 
> > path names internally. The rest should be ENOSYS.
> 
> More work for less compatibility, that doesn't sound very clever.

It's less work long term, mostly because all the rejects for sysctl.h will 
go away. And it's more compatible than just removing sysctl(2) completely.

The main reason i think at least emulating KERN_VERSION is a good idea is that
it will save a bit of time with older executables who do this 
on every startup. /proc/sys/* is a little slow to do that often.

Normally sysctls are not that time critical so this is really a 
exception.

-Andi 

Re: [PATCH] Undeprecate the sysctl system call

[Alan Cox]

Ar Mer, 2006-10-18 am 14:41 +0200, ysgrifennodd Andi Kleen:
> It's less work long term, mostly because all the rejects for sysctl.h will 
> go away. And it's more compatible than just removing sysctl(2) completely.

What rejects for sysctl.h, nobody is going to add new entries to
sysctl(2) so there will be no rejects.

Re: [PATCH] Undeprecate the sysctl system call

[Andi Kleen]

On Wednesday 18 October 2006 14:59, Alan Cox wrote:
> Ar Mer, 2006-10-18 am 14:41 +0200, ysgrifennodd Andi Kleen:
> > It's less work long term, mostly because all the rejects for sysctl.h will 
> > go away. And it's more compatible than just removing sysctl(2) completely.
> 
> What rejects for sysctl.h, nobody is going to add new entries to
> sysctl(2) so there will be no rejects.

Yes, but it still means the bizarre register_sysctl() call convention
has to be maintained internally.

If the existing sysctl.c/sysctl.h stuff wasn't needed anymore this
could be replaced with a sane

register_sysctl_name("a/b/c", &sysctl_struct) 

and clean up a lot of code.

-Andi

[PATCHv2] Undeprecate the sysctl system call

[Cal Peake]

Until something better comes along this'll get us back to the status quo.

@Andrew, this patch is a replacement for the one from yesterday.

From: Cal Peake <cp@absolutedigital.net>

Undeprecate the sysctl system call and default to always include it with
the option for embedded folks to exclude it.  Also, remove it's entry from
the feature removal file and fixup the comment in it's header file.

Signed-off-by: Cal Peake <cp@absolutedigital.net>

--- ./include/linux/sysctl.h~orig	2006-10-18 11:55:23.000000000 -0400
+++ ./include/linux/sysctl.h	2006-10-18 12:10:12.000000000 -0400
@@ -6,10 +6,9 @@
  ****************************************************************
  ****************************************************************
  **
- **  The values in this file are exported to user space via 
+ **  The values in this file are exported to user space via
  **  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.
+ **  is obsolete; instead use /proc/sys.
  **
  ****************************************************************
  ****************************************************************
--- ./init/Kconfig~orig	2006-10-17 17:54:09.000000000 -0400
+++ ./init/Kconfig	2006-10-17 18:49:36.000000000 -0400
@@ -303,20 +303,20 @@ config UID16
 
 config SYSCTL_SYSCALL
 	bool "Sysctl syscall support" if EMBEDDED
-	default n
+	default y
 	select SYSCTL
 	---help---
-	  Enable the deprecated sysctl system call.  sys_sysctl uses
-	  binary paths that have been found to be a major pain to maintain
-	  and use.  The interface in /proc/sys is now the primary and what
-	  everyone uses.
-
-	  Nothing has been using the binary sysctl interface for some
-	  time now so nothing should break if you disable sysctl syscall
-	  support, and your kernel will get marginally smaller.
+	  This option allows you to specify whether or not to build into
+	  your kernel support for the sysctl system call.  You can disable
+	  this if you are building a kernel for a system with limited
+	  resources (e.g. an embedded device) and your kernel image will
+	  shrink by a few kilobytes.
+
+	  NOTE: Disabling this option will cause a warning to be printed
+	        if a program attempts to use this system call.
 
-	  Unless you have an application that uses the sys_sysctl interface
- 	  you should probably say N here.
+	  If you are sure your userspace enviroment has no need for this
+	  system call you can say N here.
 
 config KALLSYMS
 	 bool "Load all symbols for debugging/kksymoops" if EMBEDDED
--- ./Documentation/feature-removal-schedule.txt~orig	2006-10-17 17:54:04.000000000 -0400
+++ ./Documentation/feature-removal-schedule.txt	2006-10-17 18:10:35.000000000 -0400
@@ -53,18 +53,6 @@ Who:	Mauro Carvalho Chehab <mchehab@brtu
 
 ---------------------------
 
-What:	sys_sysctl
-When:	January 2007
-Why:	The same information is available through /proc/sys and that is the
-	interface user space prefers to use. And there do not appear to be
-	any existing user in user space of sys_sysctl.  The additional
-	maintenance overhead of keeping a set of binary names gets
-	in the way of doing a good job of maintaining this interface.
-
-Who:	Eric Biederman <ebiederm@xmission.com>
-
----------------------------
-
 What:	PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
 When:	November 2005
 Files:	drivers/pcmcia/: pcmcia_ioctl.c

Re: [PATCHv2] Undeprecate the sysctl system call

[Andi Kleen]

On Wednesday 18 October 2006 18:20, Cal Peake wrote:

> -What:	sys_sysctl
> -When:	January 2007
> -Why:	The same information is available through /proc/sys and that is the
> -	interface user space prefers to use. And there do not appear to be
> -	any existing user in user space of sys_sysctl.  The additional
> -	maintenance overhead of keeping a set of binary names gets
> -	in the way of doing a good job of maintaining this interface.
> -
> -Who:	Eric Biederman <ebiederm@xmission.com>

I think the deprecation should stay.

-Andi

Re: [PATCHv2] Undeprecate the sysctl system call

[Alan Cox]

Ar Mer, 2006-10-18 am 12:20 -0400, ysgrifennodd Cal Peake:
> Until something better comes along this'll get us back to the status quo.
> 
> @Andrew, this patch is a replacement for the one from yesterday.
> 
> From: Cal Peake <cp@absolutedigital.net>
> 
> Undeprecate the sysctl system call and default to always include it with
> the option for embedded folks to exclude it.  Also, remove it's entry from
> the feature removal file and fixup the comment in it's header file.
> 
> Signed-off-by: Cal Peake <cp@absolutedigital.net>

Acked-by: Alan Cox <alan@redhat.com>

Maybe also add "Do not add new entries to these tables" to address
Andi's concern about people updating them.

Re: [PATCHv2] Undeprecate the sysctl system call

[Andrew Morton]

On Wed, 18 Oct 2006 17:41:01 +0100
Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:

> Ar Mer, 2006-10-18 am 12:20 -0400, ysgrifennodd Cal Peake:
> > Until something better comes along this'll get us back to the status quo.
> > 
> > @Andrew, this patch is a replacement for the one from yesterday.
> > 
> > From: Cal Peake <cp@absolutedigital.net>
> > 
> > Undeprecate the sysctl system call and default to always include it with
> > the option for embedded folks to exclude it.  Also, remove it's entry from
> > the feature removal file and fixup the comment in it's header file.
> > 
> > Signed-off-by: Cal Peake <cp@absolutedigital.net>
> 
> Acked-by: Alan Cox <alan@redhat.com>
> 
> Maybe also add "Do not add new entries to these tables" to address
> Andi's concern about people updating them.

I agree that those tables in sysctl.h are a right royal pita to maintain. 
And there sure is a lot of gunk in there which it would be nice to scrap.

So Andi's plan sounds reasonable to me - it'd only take a few lines to
implement sysctl(CTL_KERN/KERN_VERSION) as a back-compat thing (and it'll
be faster!).  And we add a printk so we find out which other sysctls (if
any) are being used in the wild.

?

Re: [PATCHv2] Undeprecate the sysctl system call

[Alan Cox]

Ar Mer, 2006-10-18 am 12:31 -0700, ysgrifennodd Andrew Morton:
> I agree that those tables in sysctl.h are a right royal pita to maintain. 
> And there sure is a lot of gunk in there which it would be nice to scrap.

I'm arguing that we don't maintain them, we freeze them

Re: [PATCH] Undeprecate the sysctl system call

[Eric W. Biederman]

Alan Cox <alan@lxorguk.ukuu.org.uk> writes:

>> The status quo is that we don't properly maintain sysctl.h and we arbitrarily
>> change the numbers.
>
> Not the core basic ones that are those people care about

I agree.  It just appears that the core basic ones that people
care about is the empty set.

And we the kernel developers have made no promises to keep any
of the sysctl values constant.

>From sysctl.h:
>  ****************************************************************
>  ****************************************************************
>  **
>  **  The values in this file are exported to user space via 
>  **  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.
>  **
>  ****************************************************************
>  ****************************************************************

>From the sysctl(2) man page.

> BUGS
>        The object names vary between kernel versions.  THIS MAKES THIS SYSTEM CALL WORTHLESS FOR APPLICATIONS.  Use the
>        /proc/sys interface instead.

The empirical evidence is also that no one uses sysctl, and that no one cares.

Once we can find that one user that really cares we can have serious conversations
about keeping sys_sysctl.

Eric

Re: [PATCH] Undeprecate the sysctl system call

[Alan Cox]

Ar Iau, 2006-10-19 am 09:09 -0600, ysgrifennodd Eric W. Biederman:
> > Not the core basic ones that are those people care about
> 
> I agree.  It just appears that the core basic ones that people
> care about is the empty set.

You should read linux-kernel or the other lists and look at the
complaints the deprecation caused, its not an empty set. It isn't a
large set apparently either however.

> >  **  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.

This is a bit self-referential and self-inflicted. I wish to deprecate
it wrongly because there is a comment that it is deprecated wrongly.