The problem is that there are lots of sysconf() data that can only be
reasonably provided from the kernel.
_SC_ARG_MAX // max size of argv[]+envp[]
_SC_CHILD_MAX // max number of children per process
_SC_CLK_TCK // HZ
_SC_NGROUPS_MAX // # of gids I can have
_SC_IOV_MAX // # of iovs that {read,write}v can accept
_SC_PAGESIZE // PAGE_SIZE
_SC_NPROCESSORS_CONF // # of CPUs in system
_SC_NPROCESSORS_ONLN // # of CPUs online
_SC_SEM_VALUE_MAX // maximum value a SYSV semaphore may have
_SC_SIGQUEUE_MAX // signal queue depth
_SC_SEMAPHORES // supports SYSV semaphores
_SC_SHARED_MEMORY_OBJECTS // supports SYSV shared memory
Also, from Solaris:
_SC_PHYS_PAGES // # of physical pages of RAM
_SC_AVPHYS_PAGES // # of unused physical pages of RAM
There's some others too, but these are the main ones that come to mind.
I think there are only two reasonable solutions here:
* Put everything in sysctl readonly. This doesn't need a new syscall,
but it is ugly. The other disadvantage is that we would have to
fall back on libc defaults if sysctl wasn't configured into the kernel,
which might make some machines (again, sun3 being one example)
nonfunctional. It might not be a bad idea to provide the basics
(HZ, PAGE_SIZE) this way as a stopgap, however.
* Provide a real sys_sysconf, much as we already do for IRIX, Solaris,
and SunOS compatibility. It's a trivial syscall to imlpement -
just one switch() statement.
Adding a new syscall just to return one of these values seems shortsighted
to me.
-Mitch
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/