In the wireless-extensions thread, Linus writes:
> In general, the answer to "when can we break user space" is very simple.
>
> Never.
>
> It's just not acceptable. We maintain old interfaces for years (and in
> some cases, well over a decade by now), simply because the pain from not
> doing so is horrendous, and it makes debugging impossible. You get into
> situations where users need to upgrade to tools that don't work with older
> kernels, and can thus not downgrade, etc etc.
I guess the sysctl question has been answered then,
especially since random normal apps use sysctl.
If it needs a maintainer, put me down.
I think the main problem was fixed long ago,
by assigning fixed numbers to the enum values.
Practically no other kernel code uses an enum
for an ABI, and I think we can see why.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Albert Cahalan wrote:
> In the wireless-extensions thread, Linus writes:
>
>> In general, the answer to "when can we break user space" is very simple.
>>
>> Never.
>>
>> It's just not acceptable. We maintain old interfaces for years (and in
>> some cases, well over a decade by now), simply because the pain from not
>> doing so is horrendous, and it makes debugging impossible. You get into
>> situations where users need to upgrade to tools that don't work with
>> older
>> kernels, and can thus not downgrade, etc etc.
>
> I guess the sysctl question has been answered then,
> especially since random normal apps use sysctl.
>
> If it needs a maintainer, put me down.
>
> I think the main problem was fixed long ago,
> by assigning fixed numbers to the enum values.
> Practically no other kernel code uses an enum
> for an ABI, and I think we can see why.
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
How about rewriting sysctl so that it refers to the real way (with /proc)?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFFNnIQmhCgVPlWJY8RAiTCAKDUtO4L7XqWo7+vC2vlhltdcb/L3ACfXSeM
Ii48VQu3334MkrGc23StPSA=
=pcCo
-----END PGP SIGNATURE-----
On Wed, 18 Oct 2006, Albert Cahalan wrote:
>
> I guess the sysctl question has been answered then,
> especially since random normal apps use sysctl.
I have yet to find a _single_ app that really uses sysctl, actually. Can
you name one?
There's apparently some library functions that has used it in the past,
and I've seen a few effects of that:
warning: process `wish' used the removed sysctl system call
but the users all had fallback positions, so I don't think anything
actually broke.
(The situation may be different with older libraries, which is why it's
still an option to compile in sysctl. None of the machines I had access
to cared at all, though).
Linus
On Wed, 18 Oct 2006, Linus Torvalds wrote:
> There's apparently some library functions that has used it in the past,
> and I've seen a few effects of that:
>
> warning: process `wish' used the removed sysctl system call
>
> but the users all had fallback positions, so I don't think anything
> actually broke.
Agreed, nothing seems to have broken by removing it but the warnings sure
are ugly. Is there any reason to have them? If a program relies on sysctl
and the call fails the program should properly handle the error. That
should be all the warning that's needed (i.e. report the broken program
and get it fixed).
> (The situation may be different with older libraries, which is why it's
> still an option to compile in sysctl. None of the machines I had access
> to cared at all, though).
So leave it as is for now, default to off with option to compile in if
EMBEDDED and then remove it completely in a few months?
- C.
On Wed, Oct 18, Cal Peake wrote:
> On Wed, 18 Oct 2006, Linus Torvalds wrote:
>
> > There's apparently some library functions that has used it in the past,
> > and I've seen a few effects of that:
> >
> > warning: process `wish' used the removed sysctl system call
> >
> > but the users all had fallback positions, so I don't think anything
> > actually broke.
>
> Agreed, nothing seems to have broken by removing it but the warnings sure
> are ugly. Is there any reason to have them? If a program relies on sysctl
> and the call fails the program should properly handle the error. That
> should be all the warning that's needed (i.e. report the broken program
> and get it fixed).
You will not see the warning for your failing app anyway due to the max
tries == 5 limit. With SLES10 the boot scripts trigger it already.
On Wed, 18 Oct 2006 14:52:21 -0400 (EDT)
Cal Peake <[email protected]> wrote:
> On Wed, 18 Oct 2006, Linus Torvalds wrote:
>
> > There's apparently some library functions that has used it in the past,
> > and I've seen a few effects of that:
> >
> > warning: process `wish' used the removed sysctl system call
> >
> > but the users all had fallback positions, so I don't think anything
> > actually broke.
>
> Agreed, nothing seems to have broken by removing it but the warnings sure
> are ugly. Is there any reason to have them? If a program relies on sysctl
> and the call fails the program should properly handle the error. That
> should be all the warning that's needed (i.e. report the broken program
> and get it fixed).
We should have added the sysctl numbers to that warning.
Lots of things do sysctl(KERN_VERSION), including FC5's date(1). Andi's
proposal to put some hard-wired KERN_VERSION emulator in there sounds
reasonable to me, depending upon how many other things we'll need to
emulate (which we don't know yet).
> > (The situation may be different with older libraries, which is why it's
> > still an option to compile in sysctl. None of the machines I had access
> > to cared at all, though).
>
> So leave it as is for now, default to off with option to compile in if
> EMBEDDED and then remove it completely in a few months?
It should always be an objective to remove code if we can feasibly find a
way to do so. For us to give up now and to leave all that goop in there
forever would be sad.
A patch which enhances that printk would be appreciated...
On Wed, 18 Oct 2006, Andrew Morton wrote:
> We should have added the sysctl numbers to that warning.
>
> Lots of things do sysctl(KERN_VERSION), including FC5's date(1). Andi's
> proposal to put some hard-wired KERN_VERSION emulator in there sounds
> reasonable to me, depending upon how many other things we'll need to
> emulate (which we don't know yet).
>
> A patch which enhances that printk would be appreciated...
I'll take a stab at doing that this evening if nobody beats me to it.
- C.
--
"There is nothing wrong with your television set. Do not attempt
to adjust the picture. We are controlling transmission."
-- The Outer Limits
Andrew how does this look?
Don't warn about libpthread's access to kernel.version.
When it receives -ENOSYS it will read /proc/sys/kernel/version.
If anything else shows up print the sysctl number string.
Signed-off-by: Eric W. Biederman <[email protected]>
---
kernel/sysctl.c | 22 +++++++++++++++++++++-
1 files changed, 21 insertions(+), 1 deletions(-)
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 8020fb2..19124ee 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -2676,13 +2676,33 @@ #else /* CONFIG_SYSCTL_SYSCALL */
asmlinkage long sys_sysctl(struct __sysctl_args __user *args)
{
static int msg_count;
+ struct __sysctl_args tmp;
+ int name[CTL_MAXNAME];
+ int i;
+
+ /* Read in the sysctl name for better debug message logging */
+ if (copy_from_user(&tmp, args, sizeof(tmp)))
+ return -EFAULT;
+ if (tmp.nlen <= 0 || tmp.nlen >= CTL_MAXNAME)
+ return -ENOTDIR;
+ for (i = 0; i < tmp.nlen; i++)
+ if (get_user(name[i], tmp.name + i))
+ return -EFAULT;
+ /* Ignore accesses to kernel.version */
+ if ((tmp.nlen == 2) && (name[0] == CTL_KERN) && (name[1] == KERN_VERSION))
+ goto out;
+
if (msg_count < 5) {
msg_count++;
printk(KERN_INFO
"warning: process `%s' used the removed sysctl "
- "system call\n", current->comm);
+ "system call with ", current->comm);
+ for (i = 0; i < tmp.nlen; i++)
+ printk("%d.", name[i]);
+ printk("\n");
}
+out:
return -ENOSYS;
}
--
1.4.2.rc3.g7e18e-dirty
On Wed, 18 Oct 2006, Eric W. Biederman wrote:
> if (msg_count < 5) {
> msg_count++;
> printk(KERN_INFO
> "warning: process `%s' used the removed sysctl "
> - "system call\n", current->comm);
> + "system call with ", current->comm);
> + for (i = 0; i < tmp.nlen; i++)
> + printk("%d.", name[i]);
> + printk("\n");
> }
We should prolly kill the counter now. Other than that it works for me.
Thanks Eric!
- C.
--
"There is nothing wrong with your television set. Do not attempt
to adjust the picture. We are controlling transmission."
-- The Outer Limits
On Thu, Oct 19, 2006 at 12:25:20PM -0400, Cal Peake wrote:
> On Wed, 18 Oct 2006, Eric W. Biederman wrote:
>
> > if (msg_count < 5) {
> > msg_count++;
> > printk(KERN_INFO
> > "warning: process `%s' used the removed sysctl "
> > - "system call\n", current->comm);
> > + "system call with ", current->comm);
> > + for (i = 0; i < tmp.nlen; i++)
> > + printk("%d.", name[i]);
> > + printk("\n");
> > }
>
> We should prolly kill the counter now.
sysctl(2) callable by everyone including local lusers willing to fill logs.
On Thu, 19 Oct 2006, Alexey Dobriyan wrote:
> On Thu, Oct 19, 2006 at 12:25:20PM -0400, Cal Peake wrote:
> > On Wed, 18 Oct 2006, Eric W. Biederman wrote:
> >
> > > if (msg_count < 5) {
> > > msg_count++;
> > > printk(KERN_INFO
> > > "warning: process `%s' used the removed sysctl "
> > > - "system call\n", current->comm);
> > > + "system call with ", current->comm);
> > > + for (i = 0; i < tmp.nlen; i++)
> > > + printk("%d.", name[i]);
> > > + printk("\n");
> > > }
> >
> > We should prolly kill the counter now.
>
> sysctl(2) callable by everyone including local lusers willing to fill logs.
Users don't even need to write a program to do this, see logger(1). If we
keep the counter then after 5 calls we lose potential debugging info.
- C.
--
"There is nothing wrong with your television set. Do not attempt
to adjust the picture. We are controlling transmission."
-- The Outer Limits
Anyone who is interested in knowing if they have an application on
their system that actually uses sys_sysctl please run the following grep.
find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
The -perm /111 is an optimization to only look at executable files,
and may be omitted if you are patient.
Currently I don't expect anyone to find a match anywhere except in libpthreads,
if you find any others please let me know.
Eric
On Fri, 20 Oct 2006 01:05:18 -0600
[email protected] (Eric W. Biederman) wrote:
>
> Anyone who is interested in knowing if they have an application on
> their system that actually uses sys_sysctl please run the following grep.
>
> find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
>
> The -perm /111 is an optimization to only look at executable files,
> and may be omitted if you are patient.
>
> Currently I don't expect anyone to find a match anywhere except in libpthreads,
> if you find any others please let me know.
>
http://www.google.com/codesearch
there are a few hits...
On Fri, Oct 20, 2006 at 01:05:18AM -0600, Eric W. Biederman wrote:
> Anyone who is interested in knowing if they have an application on
> their system that actually uses sys_sysctl please run the following grep.
>
> find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
>
> The -perm /111 is an optimization to only look at executable files,
> and may be omitted if you are patient.
>
> Currently I don't expect anyone to find a match anywhere except in libpthreads,
> if you find any others please let me know.
glibc on ARM _requires_ sys_sysctl for userspace ioperm, inb, outb etc
emulation.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
On Fri, Oct 20, 2006 at 01:05:18AM -0600, Eric W. Biederman wrote:
>
> Anyone who is interested in knowing if they have an application on
> their system that actually uses sys_sysctl please run the following grep.
>
> find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
This assumes the binaries and/or libraries are not stripped, and they
usually are stripped. So, it is better to run something like:
find / -type f -perm /111 | while read f; do readelf -Ws $f 2>/dev/null | fgrep -q sysctl@GLIBC && echo $f; done
Jakub
Andrew Morton <[email protected]> writes:
> On Fri, 20 Oct 2006 01:05:18 -0600
> [email protected] (Eric W. Biederman) wrote:
>
>>
>> Anyone who is interested in knowing if they have an application on
>> their system that actually uses sys_sysctl please run the following grep.
>>
>> find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
>>
>> The -perm /111 is an optimization to only look at executable files,
>> and may be omitted if you are patient.
>>
>> Currently I don't expect anyone to find a match anywhere except in
> libpthreads,
>> if you find any others please let me know.
>>
>
> http://www.google.com/codesearch
>
> there are a few hits...
What were you using for search criteria?
A challenge is to weed out code that runs on BSDs where people do use sysctl.
Eric
Jakub Jelinek <[email protected]> writes:
> On Fri, Oct 20, 2006 at 01:05:18AM -0600, Eric W. Biederman wrote:
>>
>> Anyone who is interested in knowing if they have an application on
>> their system that actually uses sys_sysctl please run the following grep.
>>
>> find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
>
> This assumes the binaries and/or libraries are not stripped, and they
> usually are stripped. So, it is better to run something like:
> find / -type f -perm /111 | while read f; do readelf -Ws $f 2>/dev/null | fgrep
> -q sysctl@GLIBC && echo $f; done
Thanks the better grep helps.
Eric
Jakub Jelinek <[email protected]> writes:
> This assumes the binaries and/or libraries are not stripped, and they
> usually are stripped. So, it is better to run something like:
> find / -type f -perm /111 | while read f; do readelf -Ws $f 2>/dev/null | fgrep
> -q sysctl@GLIBC && echo $f; done
Russell King <[email protected]> writes:
> glibc on ARM _requires_ sys_sysctl for userspace ioperm, inb, outb etc
> emulation.
It looks like we have a small but interesting set of sysctl users.
The list of files below is a composite from a number of systems I have
access to, and the reply I have gotten so far. I'm still hoping to hear
from other people so I can add some other users of sysctl to my list.
I'm still investigating to see how all of these pieces are using
sysctl, and how much they care:
- radvd seems to be an upstanding user.
- libsensors seems to be using sysctls so we have no responsibility to
maintain the ABI there.
- libpthread uses sysctl but it doesn't much care.
- module_upgrade seems to be setting the printk verbosity?
The nvidia-installer sounds like a scary piece of code.
I'm puzzled why the majority of the users seem to be concentrated
in system configuration software and installers.
These
Compiling the results I have so far (Some of these are from older distros):
/sbin/kmodule
/sbin/sndconfig
/usr/X11R6/bin/Xconfigurator
/usr/bin/tiny-nvidia-installer
/usr/bin/nvidia-installer
/usr/sbin/glidelink
/usr/sbin/kudzu
/usr/sbin/module_upgrade
/usr/sbin/mouseconfig
/usr/sbin/radvd
/usr/sbin/updfstab
/usr/lib/libsensors.so.1.2.1
/usr/lib/libsensors.so.3.1.0
/usr/lib/libsensors.so.3.0.9
/usr/lib64/libsensors.so.2.0.0
/usr/lib64/libsensors.so.3.0.9
/usr/lib/python1.5/site-packages/_kudzumodule.so
/usr/lib/python2.2/site-packages/_kudzumodule.so
/usr/lib/python2.3/site-packages/_kudzumodule.so
/usr/lib64/python2.4/site-packages/_kudzumodule.so
/lib/i686/libpthread-0.10.so
/lib/i686/libpthread.so.0
/lib/i686/nosegneg/libpthread-2.4.so
/lib/libpthread-0.10.so
/lib/libpthread-0.9.so
/lib/libpthread.so.0
/lib/tls/libpthread-2.3.3.so
/lib/tls/libpthread-2.3.5.so
/lib/tls/libpthread-2.3.6.so
/lib/tls/libpthread.so.0
/lib/libpthread-2.4.so
/lib64/libpthread.so.0
/lib64/tls/libpthread.so.0
/lib64/libpthread-2.4.so
/usr/i386-glibc22-linux/lib/libpthread-0.9.so
/usr/i386-glibc22-linux/lib/libpthread.so.0
Eric
On 10/20/06, Eric W. Biederman <[email protected]> wrote:
> Jakub Jelinek <[email protected]> writes:
>
> > This assumes the binaries and/or libraries are not stripped, and they
> > usually are stripped. So, it is better to run something like:
> > find / -type f -perm /111 | while read f; do readelf -Ws $f 2>/dev/null | fgrep
> > -q sysctl@GLIBC && echo $f; done
>
> Russell King <[email protected]> writes:
> > glibc on ARM _requires_ sys_sysctl for userspace ioperm, inb, outb etc
> > emulation.
>
>
> It looks like we have a small but interesting set of sysctl users.
>
> The list of files below is a composite from a number of systems I have
> access to, and the reply I have gotten so far. I'm still hoping to hear
> from other people so I can add some other users of sysctl to my list.
So does Linux now only support GLIBC apps? That's what your
grep seems to imply. At least one of the free Pascal compilers
does not use GLIBC. You won't find a GLIBC sysctl symbol in
any of the alternate C libraries (there are many) or even in libc5.
Running your grep on developer machines is highly biased
against legacy business apps.
Despite the desires of some fanatics, Linux does support an ABI
which is used by closed-source apps. Sometimes people even
lose their source code, perhaps via corporate reorganization.
I don't expect you plan to help anybody whose business depends
on some crufty old software...?
We have lots worse cruft if you want to go on a cleaning rampage.
We have old syscalls that can't handle modern data types.
Eric W. Biederman ([email protected]) said:
> - module_upgrade seems to be setting the printk verbosity?
Reading the current verbosity; setting it is done with sys_syslog.
Could be ported to read it out of /proc/sys/kernel/printk; that's
just more lines of code. (All this code is dying anyway, so... eh,
whatever.)
Bill
On Fri, 20 Oct 2006 06:54:43 -0600
[email protected] (Eric W. Biederman) wrote:
> > On Fri, 20 Oct 2006 01:05:18 -0600
> > [email protected] (Eric W. Biederman) wrote:
> >
> >>
> >> Anyone who is interested in knowing if they have an application on
> >> their system that actually uses sys_sysctl please run the following grep.
> >>
> >> find / -type f -perm /111 -exec fgrep 'sysctl@@GLIBC' '{}' ';'
> >>
> >> The -perm /111 is an optimization to only look at executable files,
> >> and may be omitted if you are patient.
> >>
> >> Currently I don't expect anyone to find a match anywhere except in
> > libpthreads,
> >> if you find any others please let me know.
> >>
> >
> > http://www.google.com/codesearch
> >
> > there are a few hits...
>
> What were you using for search criteria?
>
> A challenge is to weed out code that runs on BSDs where people do use sysctl.
I just used "sysctl" and clicked a lot.
>From a quick scan:
http://www.google.com/codesearch?q=+sysctl+linux+-glibc+show:ezM3VpAIwOY:VqU4ELp0K4A:GC7QFUptQys&sa=N&cd=51&ct=rc&cs_p=http://www.xorp.org/releases/0.2/xorp-0.2.tar.gz&cs_f=xorp-0.2/ospfd/linux/system.C#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:dPzMrf8geLs:EbNoGzoYDAc:I-_8YloL1fY&sa=N&cd=11&ct=rc&cs_p=http://www.openwall.com/scanlogd/lib/libnet-1.1.3-RC-01.tar.gz&cs_f=libnet/src/libnet_link_bpf.c#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:QQ2BcrelppE:zZeMmMrGko0:BFmHNHvdqyA&sa=N&cd=17&ct=rc&cs_p=http://www.cpan.org/authors/id/B/BR/BRYCE/Test-Parser-1.4.tar.gz&cs_f=Test-Parser-1.4/lib/Test/Parser/Sysctl.pm#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:yqt7gBTAktI:350f8_WXUz8:J6r1Ge4gTiw&sa=N&cd=23&ct=rc&cs_p=http://darwinsource.opendarwin.org/tarballs/apsl/top-9.tar.gz&cs_f=top-9/libtop.c#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:-9-E1kR2zW0:HD_LhbY9gNM:Wt7DONTBSR4&sa=N&cd=65&ct=rc&cs_p=http://sparemint.atariforge.net/sparemint/mint/kernel/1.15.12/freemint-1.15.12-src.tar.gz&cs_f=freemint-1.15.12/tools/sysctl/sysctl.c#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:A8hxeTvi8Lc:rlNCNnWdQuo:lUO9tYzCStY&sa=N&cd=102&ct=rc&cs_p=http://www.opensource.apple.com/darwinsource/tarballs/other/OpenLDAP-69.0.2.tar.gz&cs_f=OpenLDAP-69.0.2/OpenLDAP/libraries/liblutil/uuid.c#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:8eVH0Ss2hrY:Yg_zU6fz4U8:akq5ZzLPf34&sa=N&cd=107&ct=rc&cs_p=ftp://ftp.stacken.kth.se/pub/arla/arla-0.42.tar.gz&cs_f=arla-0.42/lib/roken/getdtablesize.c#a0
http://www.google.com/codesearch?q=+sysctl+-glibc+show:NXzHfAnEMjg:ZIWovlf1IWU:WZdEzr-Zs0o&sa=N&cd=112&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/bind-9.3.2-P1.tar.gz&cs_f=bind-9.3.2-P1/lib/isc/unix/ifiter_sysctl.c#a0
Quite a lot of networking-related utilities. Including bind and openldap.
On Friday October 20th 2006 at 01:05 uur Eric W. Biederman wrote:
> Currently I don't expect anyone to find a match anywhere except in libpthreads,
> if you find any others please let me know.
/usr/bin/qemu-mipsel
/usr/bin/qemu-i386
/usr/bin/qemu-arm
/usr/bin/qemu-ppc
/usr/bin/qemu-mips
/usr/bin/qemu-armeb
/usr/bin/qemu-sparc
This is on Debian 'sid' x86-64.
--
Marco Roeland
Andrew Morton <[email protected]> writes:
>> What were you using for search criteria?
>>
>> A challenge is to weed out code that runs on BSDs where people do use sysctl.
>
> I just used "sysctl" and clicked a lot.
Ok, no secrets from hanging out at google :)
>>From a quick scan:
>
> http://www.google.com/codesearch?q=+sysctl+linux+-glibc+show:ezM3VpAIwOY:VqU4ELp0K4A:GC7QFUptQys&sa=N&cd=51&ct=rc&cs_p=http://www.xorp.org/releases/0.2/xorp-0.2.tar.gz&cs_f=xorp-0.2/ospfd/linux/system.C#a0
Definitely linux.
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:dPzMrf8geLs:EbNoGzoYDAc:I-_8YloL1fY&sa=N&cd=11&ct=rc&cs_p=http://www.openwall.com/scanlogd/lib/libnet-1.1.3-RC-01.tar.gz&cs_f=libnet/src/libnet_link_bpf.c#a0
I believe this is a false positive, I can't see how this code compiles on linux.
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:QQ2BcrelppE:zZeMmMrGko0:BFmHNHvdqyA&sa=N&cd=17&ct=rc&cs_p=http://www.cpan.org/authors/id/B/BR/BRYCE/Test-Parser-1.4.tar.gz&cs_f=Test-Parser-1.4/lib/Test/Parser/Sysctl.pm#a0
Pass through infrastructure so to see a real user would need something at a higher level.
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:yqt7gBTAktI:350f8_WXUz8:J6r1Ge4gTiw&sa=N&cd=23&ct=rc&cs_p=http://darwinsource.opendarwin.org/tarballs/apsl/top-9.tar.gz&cs_f=top-9/libtop.c#a0
>
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:-9-E1kR2zW0:HD_LhbY9gNM:Wt7DONTBSR4&sa=N&cd=65&ct=rc&cs_p=http://sparemint.atariforge.net/sparemint/mint/kernel/1.15.12/freemint-1.15.12-src.tar.gz&cs_f=freemint-1.15.12/tools/sysctl/sysctl.c#a0
>
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:A8hxeTvi8Lc:rlNCNnWdQuo:lUO9tYzCStY&sa=N&cd=102&ct=rc&cs_p=http://www.opensource.apple.com/darwinsource/tarballs/other/OpenLDAP-69.0.2.tar.gz&cs_f=OpenLDAP-69.0.2/OpenLDAP/libraries/liblutil/uuid.c#a0
No offense to apple but in I since they are BSDs they have a usable sysctl so
I have been ignoring code from there site as a likely source of false positives.
>
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:8eVH0Ss2hrY:Yg_zU6fz4U8:akq5ZzLPf34&sa=N&cd=107&ct=rc&cs_p=ftp://ftp.stacken.kth.se/pub/arla/arla-0.42.tar.gz&cs_f=arla-0.42/lib/roken/getdtablesize.c#a0
>
> http://www.google.com/codesearch?q=+sysctl+-glibc+show:NXzHfAnEMjg:ZIWovlf1IWU:WZdEzr-Zs0o&sa=N&cd=112&ct=rc&cs_p=http://gentoo.osuosl.org/distfiles/bind-9.3.2-P1.tar.gz&cs_f=bind-9.3.2-P1/lib/isc/unix/ifiter_sysctl.c#a0
>
> Quite a lot of networking-related utilities. Including bind and openldap.
It is hard to tell on portable application like that. By looking at the compiled
version bind definitely does not call sysctl. At least not the copy I have.
This is not meant to argue that the approach is worthless, but rather to show
the pain of weeding out false positives and why I started greping through
the imported symbols of binaries, on linux. At least there everything
that is found is 100% a user.
Eric
"Albert Cahalan" <[email protected]> writes:
> On 10/20/06, Eric W. Biederman <[email protected]> wrote:
>> Jakub Jelinek <[email protected]> writes:
>>
>> > This assumes the binaries and/or libraries are not stripped, and they
>> > usually are stripped. So, it is better to run something like:
>> > find / -type f -perm /111 | while read f; do readelf -Ws $f 2>/dev/null |
> fgrep
>> > -q sysctl@GLIBC && echo $f; done
>>
>> Russell King <[email protected]> writes:
>> > glibc on ARM _requires_ sys_sysctl for userspace ioperm, inb, outb etc
>> > emulation.
>>
>>
>> It looks like we have a small but interesting set of sysctl users.
>>
>> The list of files below is a composite from a number of systems I have
>> access to, and the reply I have gotten so far. I'm still hoping to hear
>> from other people so I can add some other users of sysctl to my list.
>
> So does Linux now only support GLIBC apps? That's what your
> grep seems to imply. At least one of the free Pascal compilers
> does not use GLIBC. You won't find a GLIBC sysctl symbol in
> any of the alternate C libraries (there are many) or even in libc5.
>
> Running your grep on developer machines is highly biased
> against legacy business apps.
Show me a better way to prove that sysctl is used, and to
find sysctl users.
Somehow we got this idea into our heads that sysctl doesn't
matter, after we got that idea into our heads people have figured
that breaking the ABI was a don't care case. That has got to stop.
Either by deleting the syscall or by deciding to support it.
I am attempting to take that conjecture and find the truth of it.
At first approximation the conjecture appeared true. You compile
out sysctl and nothing obviously breaks.
Please feel free to find other means to list binaries, that use
sysctl. Showing that there is a diversity of users, and showing that
those users use sysctl in a variety of ways is the best way to get
all of the developers to understand that sysctl isn't something
that is unused and doesn't matter.
Arguing about ABIs and user entitlements because of those ABI doesn't
put the case anywhere near as strongly as empirical evidence does.
We support and maintain ABI's because we have users, not because it is
a good in and of itself. And our ABI currently has a mechanism to
report sysctl value is not support in this kernel, and system call is
not supported in this kernel so unless I reuse the syscall number or
the sysctl entry number I am not breaking the ABI.
I think I have found enough users to show that sysctl has users and
most likely needs to be kept. But the list I have is currently very
small, and would benefit from a larger list of users if we can find
them.
Eric