Date:	Fri, 28 Jul 2000 21:34:37 -0700 (PDT)
From:	Linus Torvalds <torvalds@transmeta.com>
To:	"Albert D. Cahalan" <acahalan@cs.uml.edu>
Subject: Re: sysconf (was Re: RLIM_INFINITY inconsistency between archs)



On Fri, 28 Jul 2000, Albert D. Cahalan wrote:
> 
> 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

Anybody who tries to create "sysconf()" to fix this can go screw
themselves.

That's the official message, yes.

I wrote code that works. I didn't test it, but the discussion is closed.
It might have syntactic problems, but it _does_ work. Better than _any_
kernel extension ever would. End of story.

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

Oh. And how do you handle 2.2.x kernels that don't have it?

How do you avoid stupid bloat?

How does the kernel know that the sysconfig values for "expr" and "bc" etc
should be? The kernel should not. The ADMINISTRATOR should!

And it _does_ handle dynamic stuff. Go back and read the message. The
administrator can _write_ to the file, for christ sake! It can be dynamic
enough to handle anything - you can even handle hot-plug memory with it,
because the admin sure as hell knows when he adds memory to the machine.
He can write a small and simple script that just updates the /etc/sysconf
file.

Trust me. It works beautifully. And the whole _point_ of it is that it's a
regular file, so that (a) it works with any kernel version without stupid
new system calls and (b) the administrator can maintain it and do the
right thing for _all_ of the system, not just the kernel-related values.

		Linus


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