std-unix@ut-sally.UUCP (Moderator, John Quarterman) (12/03/85)
Date: Tue, 26 Nov 85 21:47:31 pst From: topaz!packard!scgvaxd!trwrb!desint!geoff (Geoff Kuenning) In article <3575@ut-sally.UUCP> 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