Re: setrlimit change to prlimit change in behavior?

[Mark Wielaard <mark at klomp dot org>]

On Wed, 2017-10-18 at 13:10 -0700, Carlos O'Donell wrote:
> On 10/18/2017 12:06 PM, Mark Wielaard wrote:
> The linux man pages are not the canonical documentation for the
> interface.
> I suggest sending them a patch to adjust their documentation to
> prevent further confusion.

What would you suggest the patch say?

> At this moment you *cannot* know what the linux kernel interface is
> for setprlimit without going to the linux kernel sources, and
> getting 
> confirmation from core kernel developers to document that interface.

And if I was interested in the glibc provided prlimit function?
Where should I look for documentation/specification?

> > I cannot immediately deduce from this document which errors define the
> > contract of the linux kernel interface and which of glibc.
> 
> The linux man pages have two kinds of documentation
> 
> - linux kernel interface documentation (see futex for an example)
> 
> - API documentation (see getrlimit/setrlimit, prlimit for an example)
> 
> And it does a very good job of explaining which you are looking at.

How does it make that distinction?

I note that there are section 2 and section 3 man pages which seem to
officially refer to system calls vs library calls. But in practice it
seems the section 2 man pages describe the combined linux/glibc
contract, while the section 3 man pages (if they exist) describe the
standardized/posix variants (and so don't document the GNU extensions,
which you have to lookup in section 2).

> I hope that answers your question and give you some insight into what
> is going on and why. I also hope it spurs you into action to help
> Michael Kerrisk make the linux man pages a better project by
> contributing fixes.

It answers my question partly :) Yes, for my valgrind work I would like
documentation of "pure" bare linux kernel syscalls so that we can make
valgrind memcheck better at checking the syscall contract. But as
"normal" GNU/Linux hacker I find the combined explanation much more
useful. Who in their right mind is going to write anything against bare
bones linux kernel syscalls? It is the glibc wrappers that make it a
useful interface, so it makes sense to document them in combination
IMHO (so I believe the section 2 man pages are much more useful than
the section 3 man pages).

Thanks,

Mark