[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CBDB385.6080100@linux.intel.com>
Date: Tue, 19 Oct 2010 17:04:37 +0200
From: Andi Kleen <ak@...ux.intel.com>
To: "Eric W. Biederman" <ebiederm@...ssion.com>
CC: Amerigo Wang <amwang@...hat.com>, linux-kernel@...r.kernel.org,
Randy Dunlap <rdunlap@...otime.net>,
Mauro Carvalho Chehab <mchehab@...hat.com>,
Len Brown <len.brown@...el.com>, Ingo Molnar <mingo@...e.hu>,
Andrew Morton <akpm@...ux-foundation.org>,
David Howells <dhowells@...hat.com>,
Eric Paris <eparis@...hat.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Eric Dumazet <eric.dumazet@...il.com>,
"David S. Miller" <davem@...emloft.net>,
Andy Shevchenko <ext-andriy.shevchenko@...ia.com>,
linux-doc@...r.kernel.org
Subject: Re: [PATCH 2/2] sysctl: remove sysctl syscall
> At the time the deprecation was written we nearly we were in the late
> rc's before anything that cared in practice. glibc has stopped even
> providing a sys_sysctl wrapper now.
What matters are old glibc installations, not new ones.
>> I think it's ok to remove the full tables, but keeping
>> a wrapper just for the functionality glibc use(s/d) is still a good
>> idea.
> I think the only problem should be the arm glibc. I don't know if
> it's iopl implementation ever got weened off of this. I tried
> but I didn't have good test machine and submitting patches to
> glibc is much more of a pain than kernel patches.
Eric, I think you have the wrong approach here: it doesn't matter what
new glibc does,
but what any old glibcs do. If any old one uses it we cannot simply
remove it.
> To my knowledge there has never been a version of x86 glibc that
> had problems if sys_sysctl returns -ENOSYS, and glibc proper removed
> even that dependency almost as soon as sys_sysctl was deprecated.
>
AFAIK older glibc didn't use some functionality in the kernel if they
couldn't
figure out the right kernel version. And they were using sysctl for this.
> Last time we discussed this (when I added the compatibility wrapper)
> I couldn't even find a version of glibc that used sysctl, and I could
> not find a distribution old enough that still had a version of glibc
> that used sysctl on x86.
When I did my really old work for sysctl_binary() I ran into this problem.
All glibc binaries on my distribution back then used sysctl.
> We warn on every sys_sysctl value now even the glibc uses and perhaps I
> am blind but I haven't seen any bug reports. So we should be safe
> turning this off.
>
I don't so. I don't think we can that easily break compatibility, sorry.
Binary compatibility is something very important for Linux.
Anyways I'm fine with removing the bulk of the tables, but not the compat
table for the one glibc uses.
I think the code could be a lot simplified and just provide support
for the single kernel version sysctl though (I had a patch to do that
back then)
-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists