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
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
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 <[email protected]>
Restore the deprecated sysctl system call option for non-embedded users
and mark it clearly deprecated.
Signed-off-by: Cal Peake <[email protected]>
--- ./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
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.
On Tue, 17 Oct 2006 23:11:36 +0100
Alan Cox <[email protected]> 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.
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
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 <[email protected]>
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 <[email protected]>
--- ./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 <[email protected]>
-
----------------------------
-
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
Files: drivers/pcmcia/: pcmcia_ioctl.c
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 <[email protected]>
Acked-by: Alan Cox <[email protected]>
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
Cal Peake <[email protected]> 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 <[email protected]>
>
> 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 <[email protected]>
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
Ar Maw, 2006-10-17 am 21:41 -0600, ysgrifennodd Eric W. Biederman:
> > Signed-off-by: Cal Peake <[email protected]>
>
> 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
Alan Cox <[email protected]> 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
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
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
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.
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
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 <[email protected]>
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 <[email protected]>
--- ./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 <[email protected]>
-
----------------------------
-
What: PCMCIA control ioctl (needed for pcmcia-cs [cardmgr, cardctl])
When: November 2005
Files: drivers/pcmcia/: pcmcia_ioctl.c
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 <[email protected]>
I think the deprecation should stay.
-Andi
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 <[email protected]>
>
> 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 <[email protected]>
Acked-by: Alan Cox <[email protected]>
Maybe also add "Do not add new entries to these tables" to address
Andi's concern about people updating them.
On Wed, 18 Oct 2006 17:41:01 +0100
Alan Cox <[email protected]> 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 <[email protected]>
> >
> > 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 <[email protected]>
>
> Acked-by: Alan Cox <[email protected]>
>
> 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.
?
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
Alan Cox <[email protected]> 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
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.