On Sun, 02 Dec 2007 10:11:45 PST Richard L. Hamilton wrote:
> > 6526924 kernel syscall Dis setrlimit(2)/getrlimit(2) should support
> > RLIMIT_LOCKS, *_MEMLOCK and *_PTHREAD
> Now, I can see _why_ the address space limit and process size limit are one
> and the same:
> $ grep RLIMIT_AS /usr/include/sys/resource.h
> #define RLIMIT_AS RLIMIT_VMEM
> but at the shell level, I wonder if it's not a little misleading to have them
> both; it leaves the
> impression that they can be set individually.
so which one should ksh drop when RLIMIT_AS==RLIMIT_VMEM?
> Perhaps it might help if the output of ulimit -a at the very least indicated
> the limits that
> were inherently read-only on a given platform; and in the case of limits that
> were synonyms
> on a particular platform (such as address space and process size on Solaris),
> indicated that also.
> And it's not at all clear to me what the sense of treating pipe buffer size
> and socket buffer size
> as the same is; maybe on some *BSD systems, pipe() is really socketpair(),
> but on Solaris, real
> pipe() calls result in a STREAMS based entity (onto which one can push
> STREAMS modules,
> use the STREAMS rather than the socketpair() method of passing file
> descriptors, etc). OTOH,
> I see that at least sometimes the ksh93 code maps pipe() to socketpair(); not
> sure what the
> heck it's doing on Solaris. Still, if it isn't mapping pipe() to
> socketpair(), then by using
> pathconf("/", _PC_PIPE_BUF) it's lying about the socket buffer size, and if
> it is, it's lying about both.
> So in addition to adding some other limits, rationalizing what ksh93 does
> with the existing ones
> on Solaris might not be a bad idea. (and the limit that some systems have,
> RLIMIT_RSS, also
> sounds rather tempting if one's going to be thinking of adding limits; I'd
> think it would be
> much more useful in most cases than RLIMIT_LOCKS, for example)
ksh93 ulimit is driven from this const table in ksh93/data/limits.c
const Limit_t shtab_limits[] =
{
"as", "address space limit", RLIMIT_AS, 0, 'M',
LIM_KBYTE,
"core", "core file size", RLIMIT_CORE, 0, 'c',
LIM_BLOCK,
"cpu", "cpu time", RLIMIT_CPU, 0, 't',
LIM_SECOND,
"data", "data size", RLIMIT_DATA, 0, 'd',
LIM_KBYTE,
"fsize", "file size", RLIMIT_FSIZE, 0, 'f',
LIM_BLOCK,
"locks", "number of file locks", RLIMIT_LOCKS, 0, 'L',
LIM_COUNT,
"memlock", "locked address space", RLIMIT_MEMLOCK, 0, 'l',
LIM_KBYTE,
"nofile", "number of open files", RLIMIT_NOFILE, "OPEN_MAX", 'n',
LIM_COUNT,
"nproc", "number of processes", RLIMIT_NPROC, "CHILD_MAX", 'u',
LIM_COUNT,
"pipe", "pipe buffer size", RLIMIT_PIPE, "PIPE_BUF", 'p',
LIM_BYTE,
"rss", "resident set size", RLIMIT_RSS, 0, 'm',
LIM_KBYTE,
"sbsize", "socket buffer size", RLIMIT_SBSIZE, "PIPE_BUF", 'b',
LIM_BYTE,
"stack", "stack size", RLIMIT_STACK, 0, 's',
LIM_KBYTE,
"threads", "number of threads", RLIMIT_PTHREAD, "THREADS_MAX", 'T',
LIM_COUNT,
"vmem", "process size", RLIMIT_VMEM, 0, 'v',
LIM_KBYTE,
{ 0 }
};
an iffe test defines RLIMIT_UNKNOWN and redefines any RLIMIT_* not
supported on the local system to RLIMIT_UNKNOWN
the only id that does not directly correspond to a RLIMIT_* is "threads" vs
RLIMIT_PTHREAD
the limits with string entries, e.g., "nproc" => "CHILD_MAX", defer to
astconf(3)
(a library interface to confstr(2) sysconf(2) pathconf(2) and getconf(1))
so it would be possible to annotate "readonly" the RLIMIT_UNKNOWN entries that
defer to astconf()
to add a new limit that has a corresponding RLIMIT_* or astconf() string,
simply add a new table entry
that will also take care of the --man/--html self- documentation and table
annotations
the implementation uses the table index as a bitmask
so it is limited to sizeof(long)*8 entries
-- Glenn Fowler -- AT&T Research, Florham Park NJ --
