Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ut-sally.UUCP
Path: utzoo!linus!gatech!seismo!ut-sally!std-unix
From: std-unix@ut-sally.UUCP (Moderator, John Quarterman)
Newsgroups: mod.std.unix
Subject: Re:  limits
Message-ID: <3530@ut-sally.UUCP>
Date: Fri, 15-Nov-85 19:37:00 EST
Article-I.D.: ut-sally.3530
Posted: Fri Nov 15 19:37:00 1985
Date-Received: Sat, 16-Nov-85 03:57:32 EST
Organization: IEEE/P1003 Portable Operating System Environment Committee
Lines: 30
Approved: jsq@ut-sally.UUCP

Date:     Fri, 15 Nov 85 11:10:55 EST
From: Dan Franklin <dan@BBN-PROPHET.ARPA>

> ... There
> should be just *one* call that gets all the limits into a struct;
> Berkeley compatability can be achieved with "wrapper" routines.

I agree that there should be one system call, but not this one.  This one means
that if a manufacturer wants to add a limit in a later version of the system
(either in response to a change to the standard, or to enhance his system) it's
once again necessary to recompile everything that might use the system call, in
order to be able to return the larger structure.  You can solve this problem by
defining the system call to take a pointer and a length, rather than just a
pointer; then the only time recompilation is necessary is if a limit is deleted
(and you want to reclaim the structure element).  But why should it be
necessary at all?

Instead of one system call which returns *everything*, there should be one
system call which takes a numeric index "naming" the limit to be returned.  An
index of 0 would return the total number of limits. Limits.h would give the
indices.

Letting the system call "know" what limit you're actually interested in also
permits (in theory) programs to be monitored (in the kernel) to see what limits
they are requesting, so that you can know ahead of time what programs would
benefit from changing what parameters.

	Dan

Volume-Number: Volume 3, Number 21