All of lore.kernel.org
 help / color / mirror / Atom feed
From: Adrian Bunk <bunk@stusta.de>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: removed sysctl system call - documentation and timeline
Date: Wed, 4 Oct 2006 23:14:28 +0200	[thread overview]
Message-ID: <20061004211428.GB16812@stusta.de> (raw)
In-Reply-To: <9a8748490610041335t519678d1u61f5775293c061e4@mail.gmail.com>

On Wed, Oct 04, 2006 at 10:35:01PM +0200, Jesper Juhl wrote:
> Hi,
> 
> With recent kernels I'm getting a lot of warnings about programs using
> the removed sysctl syscal.
> 
> Examples (after 5 min of uptime here) :
> root@dragon:/home/juhl# dmesg | grep "used the removed sysctl system
> call" | sort | uniq
> warning: process `dd' used the removed sysctl system call
> warning: process `ls' used the removed sysctl system call
> warning: process `touch' used the removed sysctl system call
> 
> and more can be found...
> 
> 
> I'm not, as such, opposed to removing sysctl (and yes, I know what it
> is and what it does). What I am a little opposed to is that it is
> being removed on such short notice (unless I missed the memo) and that
> it is hidden inside EMBEDDED.
> 
> I would like to propose that, at least for 2.6.19, it be default on
> (as it is now), not hide it in EMBEDDED where people usually don't go,

This abuse of EMBEDDED is nonsense.

SYSCTL_SYSCALL should be moved above EMBEDDED (for not breaking the 
menu), and the "if EMBEDDED" removed.

> some huge deprecation warnings be added, and that it then gets the
> usual 6-12months before being removed (did it already get that and I'm
> just slow?)...  ohhh, and correct the help text; it currently says

It seems you are slow...

It's entry in Documentation/feature-removal-schedule.txt fulfills the
6 months.

> "...Nothing has been using the binary sysctl interface for some time
> now so nothing should break if you disable sysctl syscall support" -
> that's obviously false as demonstrated by the above extract from my
> dmesg...

What did actually break (a dmesg message is not a breakage)?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed


  parent reply	other threads:[~2006-10-04 21:14 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-04 20:35 removed sysctl system call - documentation and timeline Jesper Juhl
2006-10-04 20:45 ` Jeremy Fitzhardinge
2006-10-04 20:50 ` Alessandro Suardi
2006-10-04 21:14 ` Adrian Bunk [this message]
2006-10-04 21:58 ` Alan Cox
2006-10-04 22:41 ` Andi Kleen

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=20061004211428.GB16812@stusta.de \
    --to=bunk@stusta.de \
    --cc=jesper.juhl@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    /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.