A vision for Linux 2.2 -- POSIX.1b Compatibility and real-time support ---------------------------------------------------------------------- Markus Kuhn -- 1998-09-03 [The latest version of this text can be found on .] Today, the Linux kernel and libc are quite well compatible with the POSIX.1 and POSIX.2 standards, which specify system calls, library functions and shell command compatibility for UNIX-style operating systems. Some Linux distributions have even passed POSIX.1 conformance tests. However, the POSIX.1 system calls and library functions define only a minimum core functionality required by anything that looks like UNIX. Many slightly more advanced functions like mmap(), fsync(), timers, modifiable scheduling algorithms, IPC, etc., which are essential for many real world applications, have not been standardized by POSIX.1 in 1990. The new POSIX.1b standard (now officially called IEEE Std 1003.1b-1993, ISBN 1-55937-375-X, during development of the standard, it was called POSIX.4) corrects this and I believe POSIX.1b contains a large number of useful ideas for further development on Linux. In the very short introduction below, I hope to rise your interest in POSIX.1b and in real-time problems in general and to stimulate some development work in this direction. Happy reading! The new POSIX extensions focus on the requirements of real-time applications and on applications which have to perform high performance I/O. Many applications like interactive video games, high performance database servers, multimedia players and control software for all kinds of hardware require more deterministic scheduling, paging, signaling, timing and inter process communication mechanisms than what is available on traditional UNIX systems like BSD4.3. The functionality of systems like BSD4.3 has been optimized with mainframe multi-user time-sharing scenarios in mind, while operating systems for personal computers should also support real-time applications in addition. On a personal computer, it is often acceptable and desired that for example interactive games or CPU and memory intensive multimedia applications are excluded from the normal paging and scheduling strategies that try to be as fair as possible to all users of a large mainframe. The lack of real-time capability in Linux 1.2 has so far been the main reason why still a number of interesting applications that run fine on MS-DOS were unimplementable as user processes under Linux. Some examples are for instance highly reliable audio recording/replay tools, control software for astronomical CCD cameras, real-time signal processing algorithms, serial port smartcard emulators, MIDI computer music tools, etc. With the recent addition of POSIX.1b memory locking and static priority scheduling functions to Linux 1.3, this starts to change now. A lot of things still have to be implemented and your contributions are very welcome! This text summarizes, what functions have not yet been implemented and which people have already started to work on some of these. Please contact them if you want to know the status of their work or if you want to contribute. Please let me know about any progress so that I can keep this text up-to-date. In order to use the first new POSIX.1b features that have recently been added to Linux, please install a 2.0.x kernel, libc-5.3.12, and man-pages-1.11 or newer as available via ftp from sunsite.unc.edu or tsx-11.mit.edu. The latest libc is available from . The real-time-support is far from complete, but some interesting features are already available. POSIX.1b-1993 defines in addition to POSIX.1-1990 the following new concepts and functions: Improved Signals ---------------- POSIX.1b adds a new class of signals. These have the following new features: - there are much more user specified signals now, not only SIGUSR1 and SIGUSR2. - The additional POSIX.1b signals can now carry a little bit data (a pointer or an integer value) that can be used to transfer to the signal handler information about why the signal has been caused. - The new signals are queued, which means that if several signals of the same type arrive before the signal handler is called, all of them will be delivered. - POSIX.1b signals have a well-defined delivery order, i.e. you can work now with signal priorities. - A new function sigwaitinfo() allows to wait on signals and to continue quickly after the signal arrived with program execution without the overhead of calling a signal handler first. The new queued signals are a necessary prerequisite for the implementation of the POSIX.1b asynchronous I/O interface (see below). They might also provide a good interface for delivering hardware interrupts to user processes. New functions for signals are: sigwaitinfo(), sigtimedwait(), sigqueue(). Implementation status: Patches available. Patches to add the queued POSIX signals to Linux 2.1.43 are available now (1997-07) on . For more info, contact or Shyamalan Pather . Xavier Leroy wrote: "LinuxThreads provides an implementation of sigwait() because that function is required by the 1003.1c standard (the threads stuff), but my implementation is very inefficient and not 100% correct. LinuxThreads would benefit a lot from a good kernel-level implementation of the 1003.1b signals. For one thing, it would avoid hogging SIGUSR[12]. For another thing, sigtimedwait() is exactly what LinuxThreads needs to make inter-thread synchronization more efficient. I don't think I have enough time and knowledge to implement the 1003.1b signals myself, but I'd be very happy to participate in an implementation, and test it in LinuxThreads." Info about LinuxThreads: . Habeeb J. Dihu is currently working on the POSIX.1b signal kernel extensions for Linux and hopes to have some patches ready by 1997-02. He is also working on various other kernel thread extensions for better POSIX.1c support. Inter Process Communication (IPC) and memory mapped files --------------------------------------------------------- POSIX.1b now defines shared memory, messages, and semaphores. The functionality and design of these is similar or better than the System V IPC mechanisms which we have already in Linux. The major extensions compared to System V IPC are: - Strings (like filename paths) instead of integers are used now to identify IPC resources. This will allow to avoid IPC resource collisions much easier than in SysV IPC. The POSIX IPC name space should probably be made visible as a /proc/ipc subdirectory, such that the usual tools like ls and rm can be used to locate and remove stale persistent IPC resources. - Semaphores come in two flavors: kernel based semaphores (as in System V, which requires a system call for each P/V operation) and now also user memory based semaphores. Kernel based semaphores are sometimes necessary for security reasons, however they are a real pain if you want to build e.g. a high performance database: Suppose there are 20 server processes operating on a single huge B-tree in a memory mapped database file. Inserting a node with minimal blocking of concurrent accesses by the other 19 processes in a large B-tree can require around 100 semaphore operations, and this means currently 100 kernel calls :-(. With POSIX.1b's user memory based semaphores, you put all your semaphores in a piece of shared memory and the library accesses them with highly efficient test-and-set machine code. System calls will then only be necessary in the rare case of a blocking P operation. A high performance database programmer's dream and easy to implement! - In POSIX.1b, both memory mapped files and shared memory are done with the mmap() system call. The new functions for IPC are: mmap(), munmap(), shm_open(), shm_close(), shm_unlink(), ftruncate(), sem_init(), sem_destroy(), sem_open(), sem_close(), sem_unlink(), sem_wait(), sem_trywait(), sem_post(), sem_getvalue(), mq_open(), mq_close(), mq_mq_unlink(), mq_send(), mq_receive(), mq_notify(), mq_setattr(), mq_getattr(), mprotect(). Implementation status: POSIX IPC has not yet been implemented (although a part of the basic mechanisms is already available in the existing SysV IPC code). Since Linux 1.3, mmap() is fully implemented. Eric Dumas has written me that he has done some work on POSIX IPC, however there are no patches available, yet. Constantine Knizhnik has announced a library that provides some of the POSIX.1b system calls by emulating them via the corresponding BSD itimer calls and the SysV IPC calls. This library is available from . Memory locking -------------- Four new functions mlock(), munlock(), mlockall() and munlockall() allow to disable paging for either specified memory regions (mlock()) or for all pages (code, stack, data, shared memory, mapped files, shared libraries) to which a process has access (mlockall()). This allows to guarantee that for instance small time-critical daemons stay in memory which can help to guarantee response time of these processes. Under Linux, this (like many other real-time related features) is only allowed for root processes in order to avoid abuse of this feature by normal users in large time-sharing systems. Another application of memory locking are cryptographic computer security programs. Using mlock(), these systems can ensure that an unencrypted secret key or a password which is temporarily stored in a small user space array will never get in contact with the swap device, where under rare circumstances, someone might find the secret bytes even many months later. For these applications, it would be desirable if Linux allowed even non-root processes a small number of mlock()ed pages (e.g. up to four locked pages per non-root process should be ok). Implementation status: Linus has now added full POSIX.1b memory locking support to Linux alpha test kernel version 1.3.43. There exist also libc support and manual pages. So you won't have to apply the POSIX.4_locking patch from Ralf Haller any more. Synchronous I/O --------------- Databases, e-mail systems, log daemons, etc. require to be sure that the written piece of data has actually reached the harddisk, because transaction protocols require that a system crash or power failure after the write command can not harm the data any more. POSIX.1b defines the fsync() and O_SYNC mechanisms which Linux 1.2 already has. In addition, there is a very useful new function fdatasync() which requires that the data block is flushed to disk, however which does NOT require that the inode with the latest access/modification time is also flushed each time. With fdatasync(), the inode has only to be written in case the file length, file owner, or permission bits have changed. In database applications with mostly constant file sizes, where you sometimes require an fsync() after each few written blocks, but where you don't care about whether the access times in the inodes on the disc are always 100% up-to-date, fdatasync() could easily double (!) the performance of your system. There is also an msync() function for flushing a range of pages from memory mapped files to the disk. Implementation status: fsync(), fdatasync(), msync(), and O_SYNC are already available. O_DSYNC has not yet been implemented. However fdatasync() in Linux 1.3.55 is currently only an alias for fsync() and therefore not yet any more efficient than fsync(). Timers ------ - Instead of the old BSD style gettimeofday()/settimeofday() calls, POSIX.1b defines clock_gettime(), clock_settime() and clock_getres(). They offer nanosecond resolution instead of microseconds as with the old BSD calls (at least on Pentiums, a timer resolution much than a microsecond is available). In addition, you can query now the actual resolution of the timer with clock_getres(). - A new function nanosleep() allows to sleep also for less than a second (the old sleep() had only second resolution). In addition, nanosleep won't interfere with SIGALRM and in case of EINTR, it returns the time left, so you can easily continue in a while loop. - POSIX.1b defines also itimers, however instead of what the existing BSD itimers provide, you now can deal with several timers (at least 32 per process) and you have again theoretically up to one nanosecond resolution. The old itimer functions can still easily be implemented in libc for compatibility reasons using new POSIX-style itimer system calls. Implementation status: Patches available. Patches to add the POSIX clocks and timers to Linux 2.1.43 are available now (1997-07) on . For more info, contact or Shyamalan Pather . Nanosleep() is already available in Linux, but at the moment it supports only 10 ms resolution and it can optionally perform short microsecond precision busy waits of up to 2 ms length. Work on higher resolution timer mechanisms for Linux is described on . Scheduling ---------- Linux 1.2 has so far been optimized a lot as a time sharing system, where several people run application programs like editors, compilers, debuggers, X window servers, networking daemons, etc. and do word processing, software development, etc. However there are a lot of applications for which Linux is currently unusable and for which even die-hard Linux enthusiasts have to keep a stand-alone DOS version on their disk. For >90% of these applications, the fact that Linux is incapable of guaranteeing the response time of an application is the major problem. Software for controlling e.g. an EPROM programmer, a robot arm, or an astronomical CCD camera is not realizable under a classic Unix if there is no dedicated real-time controller present in the controlled device. A lot of commercially available hardware has been designed with the real-time "capability" of DOS in mind and has no own microcontroller for time-critical actions. A real-world example: I have myself spent a long frustrating time of trying to implement an interface to a pay-TV decoder for Linux (which emulates a chip card and allows you to watch pay-TV for free :-). In this application, you have to wait for an incoming byte on the serial port, then you have to wait for around 0.7 to 2 ms (never shorter, never longer, otherwise the TV decoder gets a timeout and stops!) before returning an answer byte. It is virtually impossible to implement a user process for this task under Linux 1.2, while it is trivial to do this under DOS. I am looking forward to the day when Linux provides enough real-time support for this application so that I can finally remove MS-DOS from my harddisk. For these and similar real-time applications, POSIX.1b specifies three different schedulers, each with static priorities: SCHED_FIFO A preemptive, priority based scheduler. Each process managed under this scheduling priority possesses the CPU as long as (a) it does not block itself and (b) there comes no interrupt which puts another process into a higher priority wait queue. There exists a FIFO queue for each priority level and every process which gets runnable again is inserted into the queue behind all other processes. This is the most popular scheduler used in typical real-time operating systems. Function sched_yield() allows the process to go to the end of the FIFO queue without blocking. SCHED_RR A preemptive, priority based round robin scheduling strategy with quanta. It is a very similar to SCHED_FIFO, however each process has a time quantum and the process becomes preempted and is inserted at the end of the FIFO for the same priority level if it runs longer than the time quantum and other processes of the same priority level are waiting in the queue. Processes of lower priorities will like in SCHED_FIFO never get the CPU as long as a higher level process is in a ready queue and if a higher priority process becomes ready to run, it also gets the CPU immediately. SCHED_OTHER This is any implementation defined scheduler. Under Linux it is the classic time-sharing scheduler with "nice" values, etc. Under Linux, all SCHED_OTHER processes share the common static priority value 0. For security reasons, only root processes should under Linux be allowed to get any static priority higher than the one for SCHED_OTHER, because if these real-time scheduling mechanisms are abused, the whole system can be blocked. If one is developing a real-time application, it is a very good idea to have a shell with a higher static priority somewhere open in order to be able to kill the tested application in case something goes wrong. You should be aware, that if you use X11, not only the shell, but also the X server, the window manager and xterm will require a higher static priority in order to stop processes blocking the rest of the system. Therefore, testing real-time software will usually better be done on the console. With this POSIX.1b functionality, it is possible to run real-time software under Linux by giving it root permissions and assigning it a SCHED_FIFO strategy and a higher static priority than all other classic SCHED_OTHER Linux processes. In addition, typical real-time application lock their pages with mlockall() into the memory in order to avoid being swapped out. This guarantees that the real-time application can react as soon as possible on any interrupts and that the response time will not be influenced by the complicated normal Linux time-sharing priority mechanisms or by paging. However, please read also the chapter on interrupt dispatch latency below! The new functions are here: sched_setparam(), sched_getparam(), sched_setscheduler(), sched_getscheduler(), sched_yield(), sched_get_priority_max(), sched_get_priority_min(), sched_rr_get_interval(). Implementation status: The sched_*() system calls are now available since Linux 1.3.55 (Markus Kuhn ). Although much testing, performance evaluation, and optimization with the real-time scheduler is necessary (especially with regard to "fast interrupt handling, see below), you can already use the sched_*() calls in order to get the processor exclusively. There are also libc and manual pages available. Some earlier work on this was done by David F. Carlson in his POSIX.4_scheduler patch against Linux 1.2 (still available on sunsite). Adam McKee has developed a QNX-style replacement scheduler for Linux 2.0 . Asynchronous I/O (aio) ---------------------- POSIX.1b defines a number of functions which allow to send a long list of read/write requests at various seek positions in various files to the kernel with one single lio_listio() system call. While the process continues to execute the next instructions, the kernel will asynchronously read or write the requested pages and will send signals when the task has been completed (if this is desired). This is very nice for a database which knows that it will require a lot of different blocks scattered on a file. It will simply pass a list of the blocks to the kernel, and the kernel can optimize the disk head movement before sending the requests to the device. In addition this minimizes the number of system calls and allows the database to do something else in the meantime (e.g. waiting for the client process sending an abort instruction in which case the database server can cancel the async i/o requests with aio_cancel()). Another important application of aio are multimedia systems like MPEG or sound file players and recorders. These programs want to preload the next few seconds of the data stream from harddisk into locked memory, but also want to continue showing the video on the screen at the same time without any interruptions caused by synchronous I/O. The POSIX.1b async I/O calls provide a nice way for such anticipatory loading. POSIX.1b also defines priorities for asynchronous I/O, i.e. there is a way to tell the kernel that the read request for the MPEG player is more important than the read request of gcc. On a future real-time Linux, you don't want to see any image distortions while watching MPEG video and compiling a kernel at the same time if you gave the MPEG player a higher static priority. New functions in this area are: aio_read(), aio_write(), lio_listio(), aio_suspend(), aio_cancel(), aio_error(), aio_return(), aio_fsync(). Implementation status: Richard Neitzel is working on a libaio package that uses the LinuxThreads package. The latest version is available from . Implemented options ------------------- As POSIX.1b conformance does not require the implementation of all these functions, macros have been specified for that indicate to application software which of the POSIX.1b functionality is available on this system. This way, portable software can be written that uses real-time features only when they are available. Under the latest Linux kernel and libc development versions, the following POSIX.1b macros have been defined and indicate implemented functions: _POSIX_FSYNC _POSIX_MAPPED_FILES _POSIX_MEMLOCK _POSIX_MEMLOCK_RANGE _POSIX_MEMORY_PROTECTION _POSIX_PRIORITY_SCHEDULING The POSIX.1b options indicated by the following macros have not yet been implemented under Linux: _POSIX_ASYNCHRONOUS_IO _POSIX_MESSAGE_PASSING _POSIX_PRIORITIZED_IO _POSIX_REALTIME_SIGNALS _POSIX_SEMAPHORES _POSIX_SHARED_MEMORY_OBJECTS _POSIX_SYNCHRONIZED_IO _POSIX_TIMERS General real-time problems -------------------------- Apart from implementing new POSIX.1b system calls, there are a number of other problems with the current Linux kernel that have to be solved in order to improve real-time performance. Problem 1: Interrupt dispatch latency A blocked process waiting for the end of some I/O request becomes runnable again when the CPU receives an interrupt from the I/O device that processed the request. The time that passes between the interrupt and the execution of the interrupt handler is called the "interrupt latency". The time that passes between the interrupt and the continuation of the execution of the blocked process is called the "interrupt dispatch latency". We are assuming that the blocked process is the process with the highest priority (the POSIX.1b scheduler system calls allow to ensure this). Many real-time applications require that the interrupt dispatch latency is as short as possible, some applications require even guarantees for the maximum interrupt dispatch latency (e.g. 20 microseconds). At the moment, Linux has basically two types of interrupt handlers: "fast" and "slow" ones. The "slow interrupt handlers" call the scheduler each time immediately after the interrupt has been handled. This guarantees that if the process has become runnable by handling the interrupt and has the highest priority, then it will directly get control over the CPU after the interrupt handler. This ensures a short interrupt dispatch latency, but the cost is that the scheduler is executed for each interrupt, which can cause a system performance degradation for devices with a high interrupt rate (e.g., network controllers). The slow interrupt handler do not disable other interrupts while they are being executed. This ensures a low interrupt latency, because other higher priority interrupts will not be blocked. The "slow" interrupt handler behavior is what you want for real-time applications. The "fast interrupt handlers" only mark in a bitmask that an interrupt has been handled for this device. The scheduler is NOT called after the fast interrupt handler and the process waiting on the interrupt may have to wait up to 1 s / HZ = 10 ms for the next timer interrupt which will call the scheduler again (because the timer interrupt is handled the "slow" way). "Fast" interrupt handlers are those which are installed by the driver by specifying the SA_INTERRUPT option when calling request_irq(). "Fast" interrupt handlers are the reason why for devices like the serial port, the interrupt dispatch latency can easily reach 10 ms and more. "Fast" interrupt handlers disable other interrupts while the handler is being executed. This increases interrupt latency. The Linux "fast" interrupt handlers cause very low interrupt handling overhead, but they can be the cause for a lot of headaches for real-time application developers. See linux/arch/i386/kernel/irq.c, linux/include/asm-i386/irq.h and linux/arch/i386/kernel/entry.S for implementation details of how fast and slow interrupts are handled in Linux. Examples for "slow" Linux 1.3 interrupt drivers with good interrupt dispatch latency are keyboard floppy disk timer sound cards mouse drivers some Ethernet cards Examples for "fast" interrupt drivers with bad interrupt dispatch latency are serial port some Ethernet cards most harddisk/SCSI drivers most CD-ROM drivers Especially for the serial port, it would be very nice to have a way to switch to low dispatch latency interrupt handling, such that an application can react as fast as possible on any incoming serial byte. Apart from the "fast" interrupt handler type, another important cause of latency in the serial port are the 16550 FIFO UARTs. At the moment, the UARTs are configured to trigger an interrupt (except for for bit rates < 2400 bit/s) only if the FIFO is filled with at least eight bytes or if an UART timeout has occured (this happens after four character transmission times). The 16550 chip can be configured to trigger limits 1, 4, 8, and 14, but Linux currently provides no ioctl() for this. For details about the FIFO UART, please consult the National Semiconductor PC16550D data sheet, which is available on . For real-time applications, it would be very desirable to change the FIFO trigger limit to one byte so that incoming serial bytes are immediately delivered to the waiting process. Applications that depend heavily on minimum serial port interrupt dispatch latency are for example MIDI music systems, DCF77 reference time long-wave radio signal receivers in Europe, packet radio network interfaces, and ISO 7816 smartcard interfaces. Some existing work in this area: Stuart Cheshire has implemented a "smart" interrupt handler that can switch between the classic "fast" and "slow" alternatives. The patch and explanation is available on . This way, you can get the real-time advantage of "slow" handling for the serial port without introducing a permanent system overhead even when no real-time application is active. Nick Simicich and Rik Faith have written a program called "cytune" which can change the FIFO thresholds for individual ports in the Cyclades async mux driver. Problem 2: Timer resolution On most Linux architectures, a timer interrupt occurs every 10 ms (HZ = 100). One exception is the Alpha architecture, where the timer interrupt comes every 1 ms (HZ = 1024). The macro HZ, which specifies the timer frequency, is defined in . At the moment, the kernel timer mechanism, on which the itimer and nanosleep implementation is based, checks after each timer interrupt whether a software timer has expired, makes the corresponding process runnable again, and calls the scheduler. This means that a highest priority real-time process can have to wait up to 2 * (1 s / HZ) = 20 ms longer than requested. An excellent solution would be to implement an interrupt-on-demand timer facility. The 8253 timer/counter chip in the PC would then have to be programmed such that it delivers an interrupt with microsecond precision exactly at the time when a software timer expires. This would increase the software timer precision by a factor of 10 000! As the 8253 timer would be programmed in a single shot mode, a lost interrupt might cause an accidental system halt. If this is problem, the CMOS battery clock, which can also be used to implement periodic interrupts, should be utilized to trigger periodic calls to the scheduler in order to ensure process preemption and kernel clock update. The time stamp counter (TSC) available in all Pentium processors is a 64-bit counter clocked at CPU frequency. It can be used on Pentium systems in order to get extremely precise timing information with theoretically close to nanosecond resolution and without overflow problems. Some existing work in this area: Balaji Srinivasan and Shyam Pather work on a microsecond resolution timer mechanism in Linux. Further information is available on . There exists an RT-Linux project that develops a Linux kernel version with hard real-time tasks. This system does not use the POSIX.1b API for accessing the real-time features. For more information contact or check the paper on . Literature ---------- For those of you who have become interested in POSIX.1b, there exists a good book: Bill O. Gallmeister, POSIX.4 -- Programming for the Real World, O'Reilly & Associates, 1995, ISBN 1-56592-074-0. This book is not only a good introduction into POSIX.1b (which was originally called POSIX.4), it is also an easy reading nice way into the world of real-time operating systems for those developers who have so far been very UNIX and time-sharing oriented. NEW: IEEE and ISO have recently published the 1996 revision of POSIX.1. This new edition now incorporates the extensions for real-time support (POSIX.1b, POSIX.1i) and threads (POSIX.1i): ISO/IEC 9945-1:1996 (ANSI/IEEE Std 1003.1, 1996 Edition), Information technology--Portable Operating System Interface (POSIX) Part 1: System Application Program Interface (API) [C Language], 896 pages, ISBN 1-55937-573-6, IEEE order number SH94352-NYF. Price: 120 USD (first copy for IEEE members: 84 USD). You can order this standard as well as all other IEEE standards directly from IEEE: phone: +1 908 981 1393 (TZ: eastern standard time) 1 800 678 4333 (toll free from US+Canada only) fax: +1 908 981 9667 e-mail: stds.info@ieee.org Information about POSIX and other IEEE standards is available on and some information about POSIX on . Unfortunately the full standard documents are only available as books or on CD-ROM, not on the Internet. Having access to the POSIX specs is certainly a good idea for any Linux kernel hacker. Here is a brief list of the POSIX standards: IEEE 1003.0 + Guide to POSIX IEEE 1003.1 + System API (C language) IEEE 1003.1a System API extensions (symlinks, etc.) IEEE 1003.1b - Real-time and I/O extensions (was: POSIX.4) IEEE 1003.1c - Threads (was: POSIX.4a) IEEE 1003.1d More real-time extensions (was: POSIX.4b) IEEE 1003.1e Security extensions, ACLs (was: POSIX.6) IEEE 1003.1f Transparent network file access (was: POSIX.8) IEEE 1003.1g Protocol indep. communication, sockets (was: POSIX.12) IEEE 1003.1h Fault tolerance IEEE 1003.1i - Technical corrections to POSIX.1b IEEE 1003.1j Advanced real-time extensions IEEE 1003.1k Removable media API IEEE 1003.1m Checkpoint/restart IEEE 1003.1n Fixes to .1,.1b,.1c,.1i IEEE 1003.1p Ressource limits IEEE 1003.1q Trace IEEE 1003.2 + Shell and common utility programs (date, ln, ...) IEEE 1003.2a - More tools and utilities IEEE 1003.2b More utilities IEEE 1003.2c Security utilities IEEE 1003.2d - Batch processing utilities IEEE 1003.2e Removable media utilities IEEE 1003.5 + Ada binding to POSIX.1 IEEE 1003.5b - Ada binding to POSIX.1b real-time IEEE 1003.5c Ada binding to POSIX.1g sockets IEEE 1003.9 + FORTRAN-77 binding to POSIX.1 IEEE 1003.10 + Supercomputing profile IEEE 1003.13 Realtime profile IEEE 1003.14 Multi-processing profile IEEE 1003.18 POSIX profile IEEE 1387 System administration IEEE 1387.1 Overview IEEE 1387.2 + Software administration IEEE 1387.3 + User/group account administration IEEE 1387.4 Printer Administration IEEE 2003 Test methodology (was POSIX.3) IEEE 2003.1 + Test methods for POSIX.1 IEEE 2003.1b Test methods for POSIX.1b IEEE 2003.2 + Test methods for POSIX.2 The standards that have already been finished and published are marked with "+", the standard extentions that have been included in the latest edition of the corresponding main standard are marked with "-", all others are still drafts. If you want to follow progress on POSIX standardization, you should read the announcements in the moderated USENET group comp.std.unix. The current status is summarized in . See also the IEEE catalog . This text just summarizes POSIX.1b and related work on Linux. Many people interested in POSIX.1b support seem also to be interested in POSIX.1c support (threads). Some information about POSIX.1c support is on and . There is now a production release package called "PCthreads (tm) POSIX threads for Linux" available from . It is maintained by Michael T. Peterson . A POSIX.1c package that provides real kernel-threads using the clone() system call has been developed by Xavier Leroy and is on . Markus -- Markus Kuhn, Computer Laboratory, University of Cambridge http://www.cl.cam.ac.uk/~mgk25/ || CB3 0FD, Great Britain