All of lore.kernel.org
 help / color / mirror / Atom feed
From: Cong Wang <amwang@redhat.com>
To: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org, Randy Dunlap <rdunlap@xenotime.net>,
	Mauro Carvalho Chehab <mchehab@redhat.com>,
	Len Brown <len.brown@intel.com>, Ingo Molnar <mingo@elte.hu>,
	Andrew Morton <akpm@linux-foundation.org>,
	David Howells <dhowells@redhat.com>,
	Eric Paris <eparis@redhat.com>,
	Peter Zijlstra <a.p.zijlstra@chello.nl>,
	Eric Dumazet <eric.dumazet@gmail.com>,
	"David S. Miller" <davem@davemloft.net>,
	Andy Shevchenko <ext-andriy.shevchenko@nokia.com>,
	linux-doc@vger.kernel.org
Subject: Re: [PATCH 2/2] sysctl: remove sysctl syscall
Date: Thu, 21 Oct 2010 17:26:24 +0800	[thread overview]
Message-ID: <4CC00740.3050404@redhat.com> (raw)
In-Reply-To: <m1zku99dh4.fsf@fess.ebiederm.org>

On 10/20/10 21:54, Eric W. Biederman wrote:
> Cong Wang<amwang@redhat.com>  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.


Ok, got it.


>> 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:


This sounds ok for me.
Do you want to me to carry this patch for you and resend?

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


Thanks!

  reply	other threads:[~2010-10-21  9:22 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-10-19  8:22 [PATCH 1/2] sysctl: refactor __do_proc_doulongvec_minmax() Amerigo Wang
2010-10-19  8:22 ` [PATCH 2/2] sysctl: remove sysctl syscall Amerigo Wang
2010-10-19 13:22   ` Andi Kleen
2010-10-19 13:49     ` Eric W. Biederman
2010-10-19 15:04       ` Andi Kleen
2010-10-19 16:00         ` Eric W. Biederman
2010-10-20  6:06           ` Cong Wang
2010-10-20 13:54             ` Eric W. Biederman
2010-10-21  9:26               ` Cong Wang [this message]
2010-10-19 14:10     ` Andreas Schwab
2010-10-19 15:05       ` Andi Kleen
2010-10-20  5:41         ` Cong Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4CC00740.3050404@redhat.com \
    --to=amwang@redhat.com \
    --cc=a.p.zijlstra@chello.nl \
    --cc=ak@linux.intel.com \
    --cc=akpm@linux-foundation.org \
    --cc=davem@davemloft.net \
    --cc=dhowells@redhat.com \
    --cc=ebiederm@xmission.com \
    --cc=eparis@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=ext-andriy.shevchenko@nokia.com \
    --cc=len.brown@intel.com \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mchehab@redhat.com \
    --cc=mingo@elte.hu \
    --cc=rdunlap@xenotime.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.