7

From APUE

The Single UNIX Specification, a superset of the POSIX.1 standard, specifies additional interfaces that extend the functionality provided by the POSIX.1 specification. POSIX.1 is equivalent to the Base Specifications portion of the Single UNIX Specification.

The X/Open System Interfaces (XSI) option in POSIX.1 describes optional interfaces and defines which optional portions of POSIX.1 must be supported for an implementation to be deemed XSI conforming. These include file synchronization, thread stack address and size attributes, thread process-shared synchronization, and the _XOPEN_UNIX symbolic constant (marked ‘‘SUS mandatory’’ in Figure 2.5). Only XSI-conforming implementations can be called UNIX systems.

Is it correct that SUS consists exactly of POSIX and XSI?

Is it correct that Linux (or Ubuntu, Debian in particular) is POSIX compliant?

Is Linux (or Ubuntu, Debian in particular) considered XSI compliant or largely so? I ask this because then I will know whether the parts in APUE labelled for XSI apply to Linux (or Ubuntu, Debian in particular).

I am mainly interested in API, so does that mean Linux kernel suffices?

muru
  • 72,889
Tim
  • 101,790
  • 3
    Re your first question, see Is Posix a subset of Single UNIX Specification? – Stephen Kitt Sep 05 '18 at 12:46
  • 2
    Re the second question, see Why isn't GNU/Linux SUS v3+ compliant?. – Kusalananda Sep 05 '18 at 12:47
  • @Kusalananda: Your pointer points to a wrong answer: Linux had an offer to get a full (assisted by Andrew Josey) certificaton for one Dollar but after a while told the OpenGroup that they are not willing to become fully compliant. – schily Sep 05 '18 at 12:58
  • 1
    @schily was that for Linux in general (and if so, how was it defined), or a specific distribution? (Or perhaps several distributions...) – Stephen Kitt Sep 05 '18 at 13:00
  • 1
    AFAIR, this was at the end mainly caused by the people behind the GNU tools. – schily Sep 05 '18 at 13:01
  • The correct place for a right answer to that question is as an answer over there, not in question comments here. – JdeBP Sep 05 '18 at 13:32
  • This question is overly broad, as it is four questions in one. As others have pointed out, we already have questions and answers dealing with the relationships between the documents and options, and at least one of the four questions here is unnecessary. – JdeBP Sep 05 '18 at 13:34
  • POSIX/SUS is dead. Nobody cares about it anymore. Linux is the new standard, because that is what servers use. The paid standard never was truly implemented by anyone. There were always cases where each platform (even when "certified", that is just the sales label that you can buy to appear more important than you are. Like the Intel inside sticker on many laptops...) would deviate from the spec. – Has QUIT--Anony-Mousse Nov 07 '18 at 21:29
  • In particular, it requires a number of ancient dead APIs and tools, such as pax to be installed that nobody uses anymore. Going for full POSIX support is useless. And really: who cares? Does your car satisfy the horse carriage safety requirements of 1876? – Has QUIT--Anony-Mousse Nov 07 '18 at 21:33

2 Answers2

5

Linux is not fully POSIX compliant. There are e.g. system calls that behave differently (sorry I currently do not remember what the differences are exactly; I'll describe them here when I remember again).

One problem is e.g. that Linux does not include a correct waitid() system call (that delivers all 32 bits from the exit() parameter) and the Linux kernel people do not like to fix this. (waitid() has existed since AT&T System V Release 4..)

Some of the XSI features are implemented in Linux but not all of them.

bash (the way it is compiled for Linux distros) comes e.g. with a non XSI compliant echo builtin, dash does not support multi byte chars which is required by XSI. This happened after some time of POSIX adoptions after Linux got the offer to get an assisted certification for one Dollar.

If you like to get a correct overview, you might be interested to search the net for the final paper of POSIX non-compliances in Linux from Andrew Josey that has been written after the Linux people told the Opengroup that they are no longer interested in becomming POSIX compliant.

See: http://www.opengroup.org/personal/ajosey/tr20-08-2005.txt

BTW: There are rumors that Red Hat recently received a copy of the POSIX test suite, so it may be that there is a hidden ongoing certification...

JdeBP
  • 68,745
schily
  • 19,173
  • 1
    Also relevant is the section on POSIX compliance in the GNU C library manual. – Stephen Kitt Sep 05 '18 at 12:58
  • 6
    Linux is not an OS, just a kernel, so by itself it cannot be POSIX compliant. Inspur K-UX 3.0 is one example of a Linux-based system that has been certified as compliant to UNIX 03. – Stéphane Chazelas Sep 05 '18 at 13:06
  • @StéphaneChazelas or Ubuntu, Debian. I am mainly interested in API, so does that mean Linux kernel suffices? – Tim Sep 05 '18 at 13:26
  • Aide-mémoire: https://en.wikipedia.org/w/index.php?diff=prev&oldid=711347640 – JdeBP Sep 05 '18 at 13:36
  • Solaris is not compliant by default and cannot be made so because its POSIX sh (/usr/xpg4/bin/sh) has dozens of non-compliances (many of them major compared to those 32bit exit code in waitid which is a recent and unfortunate non-backward-compatible change to the standard). It still has been certified (11.4 to UNIX 07 recently) even though the OpenGroup knew plain well about those non-conformances. – Stéphane Chazelas Sep 05 '18 at 13:56
  • @Tim, POSIX is an API specification. POSIX.1 covers the C API (libc and kernel mostly), POSIX.2 the shell and utilities API. On Debian/Ubuntu that involves kernel, the GNU libc, dash (or bash or mksh as Debian supports all 3 as sh), GNU coreutils, GNU sed, GNU awk or mawk, GNU cc, make... and many other utilities most of them from the GNU project. Note that Linux is not the only kernel supported by Debian. – Stéphane Chazelas Sep 05 '18 at 14:04
  • 2
    @StéphaneChazelas: You seem to missnderstand a POSIX certification. If Martijn Dekker did make a bug report against the austin group standard, this would have resulted in an updated test suite. Getting the seal does not mean a platform is fully compliant but that it passed all tests. Any platform that got the seal needs to recheck the compliance once a year with the actual version of the test suite. The enhanced ksh88 from /usr/xpg4/bin/sh is much closer to the POSIX standard than ksh93 or bash and it seems to be changed when non-compliances are detected. – schily Sep 05 '18 at 14:16
  • @StéphaneChazelas. First of all POSIX.1 and former POSIX.2 are standards - not specifications. Nowadays POSIX.1 covers more than just APIs as it documents a shell and several commands and utilities. This occured when XCU and POSIX.2 were folded into POSIX.1 – fpmurphy Sep 05 '18 at 14:29
  • @StéphaneChazelas: I forgot that waitid() exists since 1989 and is in the standard since 1995. So it is neither a recent addition, nor is there a need to be backward compatible, since the function is completely different - well it is nearly identical to the cwait() syscall that has been designed by former AT&T engineers in 1980 while they created the first UNIX clone UNOS for Charles River Data Systems. – schily Sep 05 '18 at 14:34
  • It specifies the shell and utilities API. The conformance bugs of Solaris sh are bugs of that sh, not of the standard. The standard is fine in that regard. One can report a bug against the standard but not against the OpenGroup procedure for checking conformance other than by raising it on the ML like Martjin did. SUS changed from (sort-of) requiring the Linux behaviour for waitid() (that it be truncated to 8 bits) to the SysV behaviour in the 2016 edition IIRC. They did check with RedHat that the Linux folk would be OK with the change before doing so. – Stéphane Chazelas Sep 05 '18 at 15:02
  • You are mistaken, I reported a bug against waitid() and the test scripts have been changed. SUS never required the Linux behavior but for some time introduced a wording in other parts of the standard that could be missunterpreted to apply for waitid() as well and not only to wait() and waitpid() as intended. – schily Sep 05 '18 at 15:14
  • if Linux is not compliant then can you explain how these 2 Linux distros are Unix-certified by the Open Group: Inspur's K-UX and Huawei's EulerOS? Is there a linux distro that's UNIX certified? – phuclv Oct 22 '18 at 09:53
  • I cannot see the huawai system, but Inspur seems to be certified against a very outdated POSIX version that did come with a broken certification test for waitid(). Unless the Linux kernel people change their mind and and fix their bugs in waitid() no Linux distro is POSIX compliant. – schily Oct 22 '18 at 10:58
  • @schily both of them are certified with UNIX 03 (i.e. SUS v3), which is equal to every other updated Unix OSes except Solaris (the only Unix that is SUS v4 certified) – phuclv Oct 24 '18 at 08:13
  • 1
    @phuclv: as mentioned: The UNIX-03 test suite has a buggy test for waitid() and it is pretty useless to claim that they passed the test when they cannot run software that was designed for a POSIX compliant waitid(). The only systems on your list that are POSIX compliant with respect to waitid()are from Oracle and SCO. The Apple system from that list neither returns the pid of the waited for process, nor the exit reason. I needed to write a real compliance test for my configure in order not to use waitid() on defective systems. – schily Oct 24 '18 at 09:19
  • BTW: Solaris is the first platform that has been tested for Issue-7,TC2 and there are other systems (recent Apple systems) that have been tested for the first version of Issue-7 where the waitid() test at least check for 16 bits in the exit code. – schily Oct 24 '18 at 09:19
0

Linux is not XSI-compliant at all. For example, it does not provide the system header <stdio.h>. This is because Linux is only an operating system kernel. This kernel needs an additional userland implementation to be able to be XSI-compliant.

There are several Linux distributions that include the Linux kernel, an implementation of the C Standard Library, a shell, the various utilities and various other components.

All these parts together may possibly be XSI-compliant, but that needs to be tested and verified for each of these combinations.

Roland Illig
  • 278
  • 2
    You must be a mathematician, right? Saying Linux is only a kernel and as such can't fill the user space requirements is both entirely accurate and entirely useless in the context of the question asked. Note how they say "or Ubuntu, Debian in particular", a part you completely ignored. (A comment from 2018 under the other answer also already mentions the "just a kernel" issue.) – ilkkachu Sep 09 '22 at 19:37
  • I didn't completely ignore the Linux distributions. I said that adding various parts to the kernel might result in an XSI-compliant system. I never tried to actually prove that myself, as it would take an enormous amount of time (or the appropriate test suite), both of which I am lacking. – Roland Illig Sep 10 '22 at 10:50
  • This answer doesn't add anything to the question and completely ignores details already mentioned that prevent any system using the "Linux kernel" from being XSI-compliant regardless if they have an otherwise XSI-complaint userland. Proper waitid() support, for example, is entirely a kernel issue and being pedantic about it properly being "GNU/Linux" or whatever doesn't help the reader at all. – penguin359 Jun 26 '23 at 23:16