sysctl

sysctl

[Subba Rao]

Hi,

I am working on rebuilding a modified kernel. This is for version 2.2.18 and
on Slackware distro.

I have been looking for the command "sysctl" in my */sbin directories and I
can't seem to find it. Is this something that is an independent program that is
compiled during the kernel build? I do see a few SYSCTL options in the the
xconfig session. Is this command distro specific?

Thanks for any info or pointers.

-- 

Subba Rao
subba9@home.com
http://members.home.net/subba9/

sysctl

[Albert Cahalan]

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.

Re: sysctl

[David KOENIG]

-----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 majordomo@vger.kernel.org
> 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-----

Re: sysctl

[Linus Torvalds]

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

Re: sysctl

[Cal Peake]

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.

Re: sysctl

[Olaf Hering]

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.

Re: sysctl

[Andrew Morton]

On Wed, 18 Oct 2006 14:52:21 -0400 (EDT)
Cal Peake <cp@absolutedigital.net> 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...

Re: sysctl

[Cal Peake]

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