On Thu, Oct 19, 2023 at 4:06 PM Linus Torvalds torvalds@linux-foundation.org wrote:
On Thu, 19 Oct 2023 at 15:47, Pedro Falcato pedro.falcato@gmail.com wrote:
For mprotect()/mmap(), is Linux implementation limited by POSIX ?
No. POSIX works merely as a baseline that UNIX systems aim towards. You can (and very frequently do) extend POSIX interfaces (in fact, it's how most of POSIX was written, through sheer "design-by-committee" on a bunch of UNIX systems' extensions).
We can in extreme circumstances actually go further than that, and not only extend on POSIX requirements, but actively even violate them.
It does need a very good reason, though, but it has happened when POSIX requirements were simply actively wrong.
For example, at one point POSIX required
int accept(int s, struct sockaddr *addr, size_t *addrlen);which was simply completely wrong. It's utter shite, and didn't actually match any reality.
The 'addrlen' parameter is 'int *', and POSIX suddenly trying to make it "size_t" was completely unacceptable.
So we ignored it, told POSIX people that they were full of sh*t, and they eventually fixed it in the next version (by introducing a "socklen_t" that had better be the same as "int").
So POSIX can simply be wrong.
Also, if it turns out that we had some ABI that wasn't POSIX-compatible, the whole "don't break user space" will take precedence over any POSIX concerns, and we will not "fix" our system call if people already use our old semantics.
So in that case, we generally end up with a new system call (or new flags) instead.
Or sometimes it just is such a small detail that nobody cares - POSIX also has a notion of documenting areas of non-conformance, and people who really care end up having notions like "conformance vs _strict_ conformance".
Linus
Thanks Linus for clarifying the guidelines on POSIX in Linux.
-Jeff