[lkml]   [2000]   [Jul]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: sysconf (was Re: RLIM_INFINITY inconsistency between archs)

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

    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),
    fd, 0);
    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

    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

    It's faster than a system call too. And simpler. And requires no

    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:57    [W:0.025 / U:13.320 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site