Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/mod.std.unix.v4/text0003.txt

Internet Message Format | 1987-06-30 | 1.6 KB

Date: Tue, 26 Nov 85 21:47:31 pst
From: topaz!packard!scgvaxd!trwrb!desint!geoff (Geoff Kuenning)

In article <[e-mail]> allegra!jpl (John P. Linderman) writes:

>2)  The kernel is a lousy place to store the limits.h information.
>    It is preposterous to have a separate system call for each
>    value.  If you return a structure that includes all the values,
>    you trash existing binaries whenever you make the returned
>    structure larger by adding another value.  If you use an index
>    to return a single value, you can only port to systems that
>    agree with you on the index values.

Both of these "problems" are easily solved non-problems;  nevertheless
I think I have been convinced that a file like /etc/limits (or some
such) is a superior solution on the principle of "don't put it in the
kernel unless you have to."

Talking about his proposed solution (posted with the article, John writes
that if you try out his
>program, you will recognize one problem.  It's slow.  I claim this is
>a non-problem: look up your values once, and then run nice and fast.

Give me a break, John.  Do you seriously expect me to wait for you to
run cc and sed every time I want to start up the editor?  I realize
that your program is a quick hack, but I don't think we can just
cavalierly write off startup time.  Most BSD users already run with
TERMCAP in their environment, solely as a kludge to get around the cost
of reading through /etc/termcap.  We need to remember that startup times
*are* important, and it is very expensive to open and read through even
a small file.
--

    Geoff Kuenning
    {hplabs,ihnp4}!trwrb!desint!geoff

Volume-Number: Volume 4, Number 4