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

    > So don't complain if I'm not interested in some esoteric glibc issue that
    > I find totally removed from the kernel.
    > In particular, why curse at me when it's your own problem.

    It's a problem caused by you and the short-sighted way the kernel
    interfaces are designed so that they need constant attention. You are
    unwilling to cooperate in any way. Saying that writing a kernel
    version of sysconf/fpathconf is *my* problem is simply ridiculous.
    According to your logic it is my problem to keep the libc interface
    and it is my problem to keep (ehm, make) the kernel interface sane.
    You are happy living in the kenrel-only world. Probably using a shell
    kernel module or so since, as you mentioned, the libc problems are
    only "esoteric" problems for you.

    Why are you constantly rejecting advices and even implementations of
    proper interface for the kernel? I know that you don't think it's
    fair to compare yourself to the developers of the other (commerial)
    Unix kernels. But how about just taking a look at the interfaces?
    Why do you think they have, for instance, kernel sysond and fpathconf
    interfaces? The reason is very similar to the situation we are in
    here: they have separate groups working on the kernel and user-level
    stuff, they allow the admin to reconfigure the kernel. This all cries
    out loud for a sane and stable interface.

    If you don't want to work on these things, fine, nobody can blame you.
    But I think you owe it to all the other people working on and using
    the system to listen to their comments and accept some changes for
    which you in the kernel-only world see absolutely no need.

    Having said this it is I think time to call for volunteers ones again.
    Maybe we can actually find some if you are stating that you are
    actually willing to seriously consider using what they are coming up
    with. What is needed is:

    - very clear markings of the data structures in the kernel headers which
    can be used at userlevel. Tools of whatever fashion can then be used
    to extract them. I agree that the headers definitions should not
    affect the possibility to run the application on other platforms and
    you'll find in glibc plenty of code just to allow this. We are always
    proposing to use the very latest kernel headers even if the kernel
    which is actually used is very old.

    - write interfaces to get kernel parameters. This must come in two

    - sysconf-like for generic parameters like

    NSIG (I know that you don't think more than 64 signals are useful
    but people can and do reconfigure the sources)
    total number of processors
    online processors (parsing /etc/cpuinfo, as we do it now, is a pain)

    and possibly more in future. All these are kernel related and can
    be reconfigured. Just recently I've rewritten parts of the group
    handling in glibc since using a constant NGROUPS_MAX is not possible.
    There are people changing the constant and recompiling the kernel.
    We are even doing this in-house for some special purpose machines.

    - fpathconf-like

    must handle something like

    LINK_MAX which varies with the filesystem

    - design interfaces and data structures with a little bit of
    farsightness. I know you want to keep the resource requirements
    as low as possible and this is fine. But being limited by existing
    APIs which cannot be changed is worse and finally adds more baggage
    since you have to drag compatibility code around with you.

    Please consider these advices.

    ---------------. ,-. 1325 Chesapeake Terrace
    Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA
    Red Hat `--' drepper at `------------------------

    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.023 / U:58.308 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site