Are Unix/Linux system calls part of POSIX library functions?

Question

Are Unix/Linux system calls all or mostly in POSIX?

Many Linux/Unix programming books say that POSIX library functions may be wrappers of OS system calls, or may be not. E.g. http://www.makelinux.net/books/lkd2/ch05lev1sec1, and https://www.safaribooksonline.com/library/view/understanding-the-linux/0596005652/ch10s01.html

A part (called the Single UNIX Specification) of POSIX defines UNIX. Therefore I think POSIX defines the system calls of Unix (and of Linux).

Then are Unix/Linux system calls part of POSIX library functions?

Thanks.

Answer 1

clone(2) and inotify(7): clone is system call, inotify is group of calls, an API.

These are not listed as POSIX, and are not part of a POSIX specification. This is true for many flavors on UNIX/Linux.

Linux is generally not considered POSIX, there are ways to write code and to use the POSIXLY_CORRECT environment variable to (usually) get what you need to behave the way you expect. Solaris has similar issues which are handled by using the PATH variable, e.g., using some commands from /usr/xpg4/bin instead of /usr/bin.

On the other hand read(2) has POSIX specifications, and any system that claims POSIX-compliance is supposed to support it as defined.

So an answer to your question might be: yes and no.

Basically most of the syscalls you see in section 2 manuals are POSIX, but there is no guarantee that is the case. If you use POSIX calls as defined, you very likely will have good portability.

Answer 2

Linux system calls are listed in syscalls(2). Most are POSIX, but some are specific to Linux (e.g. signalfd(2), etc...). POSIX is a specification and does not "know" about syscalls (which, in the POSIX view, are an implementation detail).

Some functions are standardized in POSIX but implemented in Linux library code, e.g. dlopen(3) (see POSIX dlopen) built above mmap(2)...

Answer 3

Strictly speaking, your statement Therefore I think POSIX defines the system calls of Unix (and of Linux) is slightly incorrect. System calls as such are not part of POSIX. This standard defines a programming interface, i.e. functions that are required to be implemented as specified for a system to be compliant but it says nothing about whether they need to be implemented as a system call or otherwise.

While some of the POSIX defined functions are without any doubt always implemented as standard library functions, like fopen or fprintf, some other are typically implemented as system calls but nothing mandates it and whether they are might change from a release to another one. It is really up to the Unix implementation designers to decide.

In any case, only a subset of what a typical Unix or Linux kernel provides as system calls match the POSIX xsh C language interfaces.

Answer 4

There are relatively few calls defined by POSIX that are not part of Linux, or other Unix systems. They tend to be newer function calls that have simply not been implemented yet. For example, the various *at() functions may not be implemented everywhere yet, so fchmodat() is not as widely portable as fchmod() or chmod().

There are many calls that are part of Linux and Unix that are not part of POSIX. For instance, neither mount(2) nor umount(2) is mandated by POSIX, but they have been a part of Unix and Linux since time immemorial.