Messages in this thread | | | Date | Mon, 9 Nov 2009 16:46:21 +0100 | From | Andi Kleen <> | Subject | Re: [PATCH 22/23] sysctl arm: Remove binary sysctl support |
| |
> Can you name one binary sysctl value that gets accessed more > than a few times during the execution of a vaguely common > application? We're talking about microseconds for typically > write-once or read-once settings.
For example shell scripts tend to execute programs quite a lot.
> The question is just how many sysctl values you regard as both > common and performance critical.
Very little, I suspect in fact it's only one.
> > > in glibc-ports for the support of arm inb/outb. The only other > > > use in older glibc was checking to see if we ran on an SMP kernel. > > > > That older glibc is widely deployed. And it won't go away next year. > > So? Most users of old glibc are also using old kernels, and they
How do you know? At least here it's quite common to use new kernels with old user land.
> can still use the config option for the compatibility code. > There wouldn't even be a performance penalty over new glibc with > new kernels which already use procfs.
When he drops the sysctl(2) API completely the old userland will be unhappy.
> > I just think you should have two flavours of emulation layer: > > full and "common sysctls". This can be probably done with the same > > code and some strategic ifdefs. > > If it's just about code size, I totally wouldn't bother. Just put the > emulation code in loadable module and add a 'printk("Warning, %s is > using sysctl %s, wasting %d kb of kernel memory")' to it's module_init > function.
That means non modular kernels can't support old userland.
-Andi -- ak@linux.intel.com -- Speaking for myself only.
| |