Re: sysctl

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux