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.
When we change the kernel-internal HZ (and yes, it _will_ happen),
user-space won't notice. __SC_CLK_TCK is useless, and will so remain.
This is _exactly_ the kind of "nifty, far-seeing patch" that I absolutely
do not want to see.
We have interfaces, and we maintain them. Adding crap for the case where
they might not be maintained in the future is _wrong_.
> Suggestion for glibc NGROUPS_MAX problem: in the typical way of
> hacking around lack of kernel support, have glibc run a setuid-root
> executable that reads kernel memory. Use the System.map file to
> seek out a suitable spot. You get bonus points for using statistical
> methods or arch-specific disassembly of the executable code.
Oh, and pray tell what is wrong by just using the value "32"?
THERE IS NO LACK OF KERNEL SUPPORT AT ALL!
There is only a stupid push to try to be more generic than anybody
actually needs! It makes glibc slower and bigger than it needs to be, and
quite frankly I don't see the point of having a system call that returns
the value "32".
If glibc _really_ really doesn't like the fact that Linux has a constant
NGROUPS, then create a stupid configuration file in /etc/sysconf, and have
some bootup entity recomupte the constants every time. Then, the magic
sysctl() call ends up being reading that sysconf file, and it allows
sysadmins etc to even edit it (or, because it is probably better off being
a binary file, edit the file generator) if they want to artificially
report other values.
Why people want to push this kind of stupidity into the kernel is beyond
me.
Read my lips: if it doesn't change value during the running of the
machine, it should not be a system call. Getting the maximum amount of
memory (_SC_PHYS_PAGES) is another example of where asking for a system
call is _stupid_. Same goes for __SC_PAGESIZE - even if it will change in
future kernels (possible), it will NOT change dynamically. You can have a
config file.
Why a config file? Simple: it breaks the linkage between kernel and glibc.
There are too many interdependencies as-is (the stupid header files that
this flame war started over being one of them). Don't add more. Instead,
work on making things more independent, so that there are no features
holding up development.
Think about this for a moment. Say I add a system call that I call
"sys_return_32()", and glibc calls "sys_sysconf_NGROUPS()". What does that
result in? glibc will have all that stupid compatibility crap, and the
sysconf() routine will look like
int ngroups = sys_return_NGROUPS();
if (ngroups < 0)
ngroups = 32; /* Or whatever */
return ngroups;
Does anybody really think that the above is beatiful? Multiply the above
by every single new thing that some deranged POSIX.76c standard comes up
with, and it's obviously crap.
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");
if (fd < 0)
return fd;
map = mmap(NULL, _SC_MAX*sizeof(long),
PROT_READ, MAP_PRIVATE,
fd, 0);
close(fd);
if (map == MAP_FAILED)
return -1;
sc_map = map;
}
return map[name];
}
which can (a) handle every single sysconf name in existence with the same
code (preferably the sysconf names are well-chosen to not be all over the
place, but you can easily group them and take advantage of holes - but
remember that not all filesystems like holes). And (b) doesn't need any
backwards compatibility crap. And (c) is something glibc can do on it's
OWN.
And you know what?
It's easily expandable.
It doesn't matter where the values basically come from:
_SC_CHILD_MAX comes from the kernel
_SC_TZNAME_MAX comes from glibc
_SC_BC_BASE_MAX comes from "bc"
_SC_EXPR_NEST_MAX comes from "expr"
_SC_RE_DUP_MAX comes from the regexp library
..etc..
It's faster than a system call too. And simpler. And requires no
infrastructure.
So how about some people start using their brains, instead of blaming the
kernel for some lack of infrastructure.
And yes, I mean you in particular, Uli. Instead of trying to come up with
something clever and complicated, why don't you come up with something
INTELLIGENT and simple. See above.
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/
This archive was generated by hypermail 2b29 : Mon Jul 31 2000 - 21:00:27 EST