Re: sysconf (was Re: RLIM_INFINITY inconsistency between archs)

From: Albert D. Cahalan (acahalan@cs.uml.edu)
Date: Fri Jul 28 2000 - 16:54:59 EST


Linus Torvalds writes:
> On Fri, 28 Jul 2000, Albert D. Cahalan wrote:

>> We should export the "user jiffies". Eventually this _may_ become a
>> real per-arch constant, but for now it is not. For now it is just HZ,
>> and you can't stop people from adjusting it. User-space already has
>> to hack around the lack of __SC_CLK_TCK, and I assure you that it is
>> very gross... the procps code could make you vomit.
>
> This is not as hard as it seems. HZ is 100 on intel, as far as user mode
> is concerned. End of story.

So, officially, does this mean:

1. anybody needing greater resolution in /proc can go screw themselves
2. anybody wanting a fast HZ without hacking /proc can do likewise
3. anybody needing more than 32 groups can do likewise
4. app and libc developers should not try to help these people

It is your kernel of course, but the above is really cruel.
You increased the max number of processes, bytes in a file, and
valid user IDs. Were those not all interfaces of equal standing?

> We have interfaces, and we maintain them. Adding crap for the case where
> they might not be maintained in the future is _wrong_.

The interface is defined as using sysconf() so that you _don't_ need
to have magic constants that remain unchangable for all eternity.
With that, "NGROUPS is 32" is no longer an interface that must be
maintained -- you get the freedom to change it.

Having some boot script hack up numbers via testing the limits
is truly gross, especially since testing some of the limits is
pretty much a self-inflicted DoS attack.

> Now, how about a sysconf() that looks like
>
> long sysconf(int name)
> {
> static long *sc_map = NULL;
> long *map = sc_map;
>
> if (name < 0 || name >= _SC_MAX) {
> errno = EBADNAME;
> return -1;
> }
>
> if (!map) {
> int fd = open("/etc/sysconf");

That won't handle dynamic stuff, like the number of online processors.
Make it /dev/sysconf and the problems go away.

-
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/



This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:28 EST