Received: from SOUTH-STATION-ANNEX.MIT.EDU by po7.MIT.EDU (5.61/4.7) id AA29374; Sat, 16 Mar 96 19:29:11 EST Received: from SENATOR-BEDFELLOW.MIT.EDU by MIT.EDU with SMTP id AA21043; Sat, 16 Mar 96 19:28:24 EST Received: (from root@localhost) by senator-bedfellow.MIT.EDU (8.6.13/2.3JIK) id TAA28439 for Linux-Development-System-Dist@senator-bedfellow.mit.edu; Sat, 16 Mar 1996 19:23:02 -0500 Message-Id: <199603170023.TAA28439@senator-bedfellow.MIT.EDU> From: Digestifier To: Linux-Development-System@senator-bedfellow.MIT.EDU Reply-To: Linux-Development-System@senator-bedfellow.MIT.EDU Delivered-To: Linux-Development-System@senator-bedfellow.mit.edu Precedence: bulk Date: Sat, 16 Mar 96 19:19:52 EST Subject: Linux-Development-System Digest #514 Linux-Development-System Digest #514, Volume #2 Sat, 16 Mar 96 19:19:52 EST Contents: Status of POSIX.1b real-time support (Markus Kuhn) Re: remount problem (Ian T Zimmerman) Threads for linux (Chet Vora) [1.3.73] - setterm/termcap problem (Peter F. Gray) ---------------------------------------------------------------------------- From: mskuhn@unrza3.dialin.rrze.uni-erlangen.de (Markus Kuhn) Subject: Status of POSIX.1b real-time support Date: 16 Mar 1996 20:29:43 +0100 Reply-To: mskuhn@cip.informatik.uni-erlangen.de [This is another update of the text about implementing POSIX real-time features in the Linux kernel which I posted here a few weeks ago. I added information about the new POSIX.1(1996) near the end and some other new information. Markus] A Vision for Linux 2.0 -- POSIX.1b Compatibility ================================================ Markus Kuhn -- 1996-03-16 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. 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. 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 e.g. 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 e.g. highly reliable audio recording/replay tools, control software for astronomical CCD cameras, real-time signal processing algorithms, serial port smartcard emulators, 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 wellcome! 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. 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 quicklyafter the signal arrived with program execution without the overhead of calling a signal handler first. New functions for signals are: sigwaitinfo(), sigtimedwait(), sigqueue(). Implementation status: not yet implemented. Kevin Tran has sent me a short note that he has started to do some work on POSIX.1b signals for Linux. 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 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, so 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 B-tree in a memory mapped database file. Inserting a node with minimal blocking of other concurrent accesses by the other 19 processes in a large B-tree can require around 100 semaphore operations, i.e. 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 are now only 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 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. 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 e.g. small time-critical daemons stay in memory which can help to guarantee response time of these processes. Under Linux, this (like most other real-time related features) should of course only be allowed for root processes in order to avoid abuse of this feature by normal users in large time-sharing systems. Another application would be in 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. So you won't have to apply the POSIX.4_locking patch from Ralf Haller any more. Synchronous I/O =============== Databases, e-mail systems, etc. require to be sure that the written piece of data has actually reached the harddisk, because transaction protocols require that a power failure after the write command can not harm the data. 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 has 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 not yet fully implemented. Timers ====== - Instead of the old BSD style gettimeofday()/settimeofday() calls, POSIX.1b defines clock_gettimer(), clock_settimer() and clock_getres(). They offer nanosecond resolution instead of microseconds as with the old BSD calls (at least on Pentiums, it is not difficult to implement a timer with a resolution much better than a microsecond). In addition, you can query now the actual resolution of the timer with clock_getres() (this might e.g. be higher on a Pentium than on an i386 if the Pentium clock count registers are utilized). - 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. In order to implement this correctly with really high resolution (i.e. with better than 10 ms resolution), the 100 Hz interrupt in sched.c would have to check each time whether during the next time slice, a nanosleep() is scheduled to wake up and it would have to reprogram the interrupt timer to interrupt at precisely this time. If well done, this could be implemented without performance reduction for users of systems which do not use a nanosleep() at the moment and it would bring Linux (together with the POSIX.1b scheduler extensions below) a lot towards real-time capability. - 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: The POSIX itimers have not not yet been implemented, although much of the functionality is already available in the form of the BSD timers and adding them should be quite easy. Queued Signals have to be implemented first. Nanosleep() is now also 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. Extending nanosleep() and the itimers to microsecond precision would require a major reorganization of the Linux kernel timer mechanisms. Certainly an interesting project ... 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 currently not realizable under Linux 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, so this is a real world problem. 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 and would for Linux obviously be the the current time-sharing scheduler with "nice" values, etc. For simplicity, I suggest that under Linux 1.4, all SCHED_OTHER processes should have the lowest static priority level and that all SCHED_RR or SCHED_FIFO processes can only have higher priorities. Inside this common lowest SCHED_OTHER priority level, the classic Linux scheduling algorithm would determine the Linux scheduler priority which decides which process gets the CPU next depending on nice levels, how long the process has already had the CPU, etc. as it is done already now. 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 SCHED_FIFO 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 the xterm will require a higher SCHED_FIFO or SCHED_RR 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 would be 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, this real-time application would lock its pages with mlockall() into the memory in order to avoid being swapped out. This will guarantee 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. Then the only final piece missing towards a full real-time OS like QNX or LynxOS would be a preemptable kernel (BTW: has Windows NT a preemptable kernel?). However this is a much more complicated task (as the kernel won't be a monitor any more) and I have some doubts whether implementing this last step is possible without a noticeable performance loss. 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, you can already use the sched_*() calls in order to get the processor exclusively. Some earlier work on this was done by David F. Carlson in his POSIX.4_scheduler patch against Linux 1.2 (available on sunsite). 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 e.g. 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 players 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 e.g. showing the video on the screen at the same time without any interruptions caused by synchronous I/O. 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: Not yet implemented. The aio functions are probably best implemented in libc using kernel threads and the normal synchronous I/O system calls. There has recently been some progress on implementing kernel threads in Linux 1.3 using the clone() system call. Adding priority I/O to Linux might be a more complicated job, because many device drivers would have to be extended by priority wait queues. 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 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. You can order the POSIX.1b standard (officially called IEEE Std 1003.1b-1993; this book includes also all text of POSIX.1 and costs 114 USD) as well as the other POSIX standards directly from IEEE: phone: +1 908 981 1393 (TZ: eastern standard time) 1 800 678 4333 (from US+Canada only) fax: +1 908 981 9667 e-mail: stds.info@ieee.org Information about POSIX and other IEEE standards is also available on , however 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 some of the POSIX standards: POSIX.1 Basic OS interface (C language) POSIX.1a Misc. extensions (symlinks, etc.) POSIX.1b Real-time and I/O extensions (was: POSIX.4) POSIX.1c Threads (was: POSIX.4a) POSIX.1d More real-time extensions (was: POSIX.4b) POSIX.1e Security extensions, ACLs (was: POSIX.6) POSIX.1f Transparent network file access (was: POSIX.8) POSIX.1g Protocol independent communication, sockets (was: POSIX.12) POSIX.1i Technical corrections to POSIX.1b POSIX.2 Shell and common utility programs (date, ln, ...) POSIX.3 Test methods POSIX.5 ADA binding to POSIX.1 POSIX.7 System administration POSIX.9 FORTRAN-77 binding to POSIX.1 POSIX.15 Supercomputing extensions (checkpoint/recovery, etc.) and a few others which are still in early draft stage. If you want to follow progress on POSIX standardization, you should follow the announcements in the moderated USENET group comp.std.unix. ISO has also published POSIX.1 as ISO/IEC 9945-1:1990. ISO and IEEE will soon publish the new revision of this standard: ISO/IEC 9945-1:1996. This will be the new 1996 revision of POSIX.1 which will contain in one single standard POSIX.1(1990), POSIX.1b(1993), POSIX.1c(1995), and POSIX.1i(1995) (perhaps also POSIX.1a(1996) if it gets ready in time). If you want to order the POSIX standard but are not in a hurry, may be it is a good idea to wait a few months until ISO/IEC 9945-1:1996 is available. All differences between POSIX.1(1990) and POSIX.1(1996) will be marked by bars at the page margins. 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 . Markus -- Markus Kuhn, Computer Science student -- University of Erlangen, Internet Mail: - Germany WWW Home: ------------------------------ From: itz@rahul.net (Ian T Zimmerman) Subject: Re: remount problem Date: 14 Mar 1996 00:53:31 -0800 In article rabe@Mathematik.Uni-Bielefeld.DE (Matthias Rabe) writes: > > In my /etc/fstab /usr is set to be mounted read only. If I do a: > > mount -w -o remount /usr > > to change some files and then: > > mount -o remount /usr > > /usr is still mounted writable. > Are you sure it is mounted writable? Have you tried something like echo BLAH >/usr/BLAH ? The mount program can lie. It gets its information from /etc/mtab, which may not be updated (for example, if your _root_ filesystem is read only). > But if I do a: > > mount -n -w -o remount /usr > mount -n -o remount /usr > > /usr is remounted read ony. > Again , that would seem to indicate that /etc/mtab is being properly updated when you do the first remount, but (for reasons unknown) not the second. -- Ian T Zimmerman +-------------------------------------------+ P.O. Box 13445 I With so many executioners available, I Berkeley, California 94712 I suicide is a really foolish thing to do. I USA +-------------------------------------------+ ------------------------------ From: Chet Vora Crossposted-To: comp.os.linux.misc,comp.os.linux.development.apps,comp.os.linux.help, Subject: Threads for linux Date: 16 Mar 1996 20:57:15 GMT Hi guys, Forgive me if this question has appeared here before, but I would like to know if there are Multithread libraries for linux and if so where I can find them. I know of at least one- PThreads; and I downloaded version 0.9.2 from http://www.aa.net/~mtp/PCthreads.html I would be interested in knowing if there has been any other implementations or later versions. Thanks in advance, Chet -- ******************************************************************************* Chet Vora www: http://www.eng2.uconn.edu/~chet The scientific theory I like the most is that Saturn's rings are composed entirely of lost airline baggage. -Mark Russel ******************************************************************************* ------------------------------ From: pfgray1@ibm.net (Peter F. Gray) Subject: [1.3.73] - setterm/termcap problem Date: 16 Mar 1996 23:48:22 GMT I've just upgraded from 1.2.13 to 1.3.73, and when I boot I get a message /bin/setterm: Could not find termcap entry for linux did the file (termcap) move (from /etc)? or change format? ------------------------------ ** FOR YOUR REFERENCE ** The service address, to which questions about the list itself and requests to be added to or deleted from it should be directed, is: Internet: Linux-Development-System-Request@NEWS-DIGESTS.MIT.EDU You can send mail to the entire list (and comp.os.linux.development.system) via: Internet: Linux-Development-System@NEWS-DIGESTS.MIT.EDU Linux may be obtained via one of these FTP sites: nic.funet.fi pub/OS/Linux tsx-11.mit.edu pub/linux sunsite.unc.edu pub/Linux End of Linux-Development-System Digest ******************************