This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 4/5] Add a sysconf syscall
On Mon, May 16, 2011 at 12:06:40PM -0500, Steve Munroe wrote:
d Seems like the Aux Vector would do job. Simple, in memory, LIBC already
It's difficult to update the aux vector dynamically after the program has
started. Applications in theory could reuse it for something else, so it
wouldn't be safe to poke in there (and quite complex too)
One of the main motivations for the new call was _SC_NPROCESSORS_ONLN,
which can change dynamically.
So if we put that into the aux vector the program would only ever know about
the CPUs online at startup time. Not good.
> fills in some sysconf values from the auxv and has infrastructure for that.
> And the perform conscious hacker can access the auxv directly if they want.
rlimits are not static and the they don't map to clone semantics (see all the
other mails on this) Various values are based on rlimits.
vsyscalls would work for the online CPUs, but not for a lot of other things.
I suppose if this was just to solve the online cpu case it may be a suitable
solution, but I tried to be a bit more general.
Here's a handy reference table:
vdso aux syscall
constant values x x x
rlimit based values -* - x
runtime values like cpus x - x
portable to all archs - x x
performance best best good enough
coding complexity high low low
* unless you break clone and add a writable page to each program and be complex
So you can see the aux vector is not doing very well overall.
The vdso is somewhat better, but only if you sacrify the rlimits
and accept high complexity.
The syscall is imho still the sweet spot overall. It's excellent
everywhere, except it doesn't have the best performance. But it seems
good enough.
-Andi