On Thu, Oct 19, 2023 at 4:06 PM Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > > On Thu, 19 Oct 2023 at 15:47, Pedro Falcato <pedro.falcato@xxxxxxxxx> 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
