Re: [PATCH] SYSCTL: Fix sysctl breakage on systems with older glibc

[Andi Kleen]

On Thu, Dec 17, 2009 at 07:07:54AM -0800, Eric W. Biederman wrote:
> reaction would be.  If it makes logging in and manually using the
> machine unbearable on systems with versions of glibc from days of
> yore, the level of logging is too high.

The reason I was slightly annoyed is because I flagged this 
during code review and it wasn't addressed before merging.

> 
> > I see this on a SUSE 10.0 system with glibc 2.3.5.
> > Don't warn for this common case.
> 
> Perhaps it is just my sample of the world but glibc < 2.5 isn't
> common, especially on machines that I am putting new kernels on.
> Equally machines with 3+ year old installs are rare.

Linux simply cannot abandon older user land. We still (near) 
fully support a.out executables, even on 64bit.

> 
> > Signed-off-by: Andi Kleen <ak@xxxxxxxxxxxxxxx>
> >
> > diff -u linux-2.6.32-git12/kernel/sysctl_binary.c-o linux-2.6.32-git12/kernel/sysctl_binary.c
> > --- linux-2.6.32-git12/kernel/sysctl_binary.c-o	2009-12-16 12:15:52.000000000 +0100
> > +++ linux-2.6.32-git12/kernel/sysctl_binary.c	2009-12-16 12:14:58.000000000 +0100
> > @@ -1399,6 +1399,13 @@
> >  {
> >  	int i;
> >  
> > +	/* 
> > +	 * CTL_KERN/KERN_VERSION is used by older glibc and cannot 
> > +	 * ever go away.
> > +	 */
> The comment is wrong.  Older versions of glibc are perfectly happy
> getting -ENOSYS form sys_sysctl.

and it fills and fills and fills the kernel log. In practice
that's not usable.

> 
> > +	if (name[0] == CTL_KERN && name[1] == KERN_VERSION)
> > +		return;
> 
> If you make it printk_once for this case I think that strikes the right
> balance.  You won't be spammed to death by messages telling you about
> a silly old glibc, but you will be told.

It's not a "silly old glibc", it's a "perfectly functional old glibc"

-Andi
-- 
ak@xxxxxxxxxxxxxxx -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/