Softpanorama (slightly skeptical) Open Source Software Educational Society

May the source be with you, but remember the KISS principle ;-)

Unix System Calls Links

Reference

System Calls -- slides

• System call is to invoke system provided functions.

• System calls deals with sytem level resources, such as memory allocation, setting time, create new process, etc.

• Real system calls are done in the form of interrupts. Assembly level coding. Inconvenient to use.

• What we normally use are the system library functions which put wraps over the system calls, so we can use the familiar function call interfaces.

• The system library functions are often at too low a level, you may want to wrap it in your own routines.

• Many functions can be made accessible through #include <.h>

• man page of functions always tell you what include file to use.

• Allocating memory dynamically, e.g. buiding a linked list.

mail() {

struct rec { char name[20];

int number;

struct rec *next; }

struct rec *a; /* declare the pointer */

a = (struct rec *) malloc(sizeof(struct rec)); /* get the memory */

a-> = (struct rec *) malloc(sizeof(struct rec)); /*get another one*/

scanf("%s %d", a->, &(a->));

….

free(a); /* release the fist node and loose the second */

}

-->

• Use system() . ( #include <.h> )

• Example: the list of current directory and print it.

mail( ) {

FILE *fp, *fopen(); char c;

system("ls -l > tmp"); /* invoking bourne shell */

fp = fopen("tmp", "r");

while ( (c = getc(fp)) != EOF)) putchar(c);

fclose(fp);

}

-->

Use pipe

• Use pipe to read the results of a shell command or provide input to a shell command.

main( ) {

FILE *infp, *outfp, *popen( ); int c;

infp = popen("ls -l", "r"); /* equivelant to ls -l | thisprogram */

outfp = popen("mail qli", "w");

while ( ( c = getc(infp)) != EOF) fprintf(outfp, "%c", c);

pclose(infp);

pclose(outfp);

}

-->

Process Control (cont.)

• Process creation/termination
  • fork( ) exit( )
  • execl( ) excelc( ) exclv( ) execv( ) execve( ) execvp( )

• Communication/synchronization
  • wait( ) pipe( ) sleep( ) alarm( ) signal( ) kill( )
  • setjmp( ) longjmp( )
  • The System V IPC:
  • msgget( ) msgsnd( ) msgrcv( ) msgctl( )
  • semget( ) semop( ) semctl( )
  • shmget( ) shmat( ) shmdt( ) shmctl( )

fork( )

• int fork( )
  • creates a new (child) process which is identical to the caller (the parent process).
  • the child process inherits:
    • the code
    • the environment
    • all signal setting
    • set user and group ids
    • time left one the alarm clock
    • current working directory
    • all open file descriptors (copies)
  • fork() returns -1 if a child cannot be created. Otherwise it returns: 0 -- if the process is the child the process id of the child -- if the processs is the parent.

Example:

….

if ( (pid == fork( )) != 0 ) {
printf("I am the parent process\n");
… other stuff
wait(&status);
}
else {
printf("I am the child process\n");
…. other child process code
}

• How many new processes will be greated if the following sequence is executed: fork( ); fork( );

Event Detection (Signal)

• Signals (interrupts) can be sent to processes. You can ignore a signal, take default action on a signal, or catch the signal.

• During the execution of a process an interrupt (singal) can be sent to the process by "kill" command, by kill( ) system call, and alarm( ) system call.

• If you program does not specify anything about signal, the default action will be taken by the system, normally termination.

• You can set up traps to catch the signals and invoke your own signal handler routines.

• Set a trap (calling signal() function):

  #include <.h>
  
  main( ) {
  ….
  signal(SIGINT, handler(SIGINT));
  /* call hander() if SIGINT arrives */

Signal (cont.)

• The handler is a function that you define as handler(int signal) { … check the signal type; … take action accordingly }

• Upon return from the handler, the execution continues from the interrupted point.

• You can use signal(SIG???, SIG_IGN) to ignore the signal SIG???. In this case your program is not disturbed.

• signal(SIG???, SIG_DFL) : take default action. Normally terminate.

• There are about 30 signals. Look at "man 5 signal". E.g., HUP, INT, KILL, STOP, ALRM, etc.

• Example:

kill -HUP pid Many system daemons catch this signal and reinitialize themselves.

Signal (cont.)

• User may generate a signal by using kill() and alarm() system call

• int kill(int process_id, int signal_name);
  • kill() function can generate any signal and send to the processs specified.

• unsigned alarm(int seconds);
  • wait the specified number of seconds and send ALRM signal to the process who called this function.

• Example: set timeout for a process

  …..
  
  signal(SIGALRM, handletimeout());
  …..
  alarm(20);
  ….
  void handletimeout() { …. }

setjmp & longjmp (<.h>)

• allow inter-fcuntion goto and bypass the usual return sequence

• int setjmp(jump_buf buf);
  • save the current state of the caller in the argument and then return 0

• void longjmp(jump_buf buf, int val);
  • Pass control to the return address stored in the first argument which was set by an earlier setjmp() call.
  • The result will appear to be a return from the last setjmp() call with the save buf.
  • The second paramemter will be the return val of setjmp(). If val is 0, setjmp() will return 1.

• Example:

#include <.h>

#include <.h>

#include </signal.h>

#define TIMEOUT 10

static jmp_buf jbuf;

main(int argc, char argv[ ]) {

FILE *fp;

int ecode;

if ( ( fp = fopen( argv[1], "r") == NULL){

perror("ca't open file"); exit(1); }

while (1) {

if (setjmp(jbuf)) == TIMEOUT ) {

printf("Timeout\n"); ecode=0; break;}

else {

signal(SIGALRM, wentoff);

alarm(10);

printf(Enter ID number:");

• 
  

if (scanf("%d%*c", &id) == EOF) {

ecode = 0; break; }

alarm(0); /* cancel alarm */

if (fseek(fp,id*sizeof(cust), 0)

==NULL) {

perror("can't seek");ecode=1;break;

} else if ( fread((char *) &cust,

sizeof(cust), 1, fp) ! = 1) {

perror("can't read");ecode=1;break;}

print_info(cust);

}} /* if, while */

} /* main() */

wentoff(int signal) {

printf("Timeout has occured\n");

longjmp(jbuf, TIMEOUT);

}

exec () family

• exce family overlay the calling process by the give program. This is the way to create a process and run a program different to the parent process.
  int execl(path, arg0 [ , arg1,... , argn ] (char *)0) char *path, *arg0, *arg1, ..., *argn;
  int execv(path, argv) char *path, *argv[ ];
• The calling process is overload by the program or interpreter (e.g. /bin/sh) specified by path (the complete path).
• The new program is executed with the given arguments.
• arg0 must be the program file name (convention).
• Use execl when the arguments are know. (char*)0 is to terminate the argument list.
• Use execv when the arguments are constructed dynamically (unknow at programming time).
• Adding on a list of environment vars
  int execle(path, arg0 [ , arg1,... , argn ] (char *)0, envp) char *path, *arg0, *arg1, ..., *argn, *envp[ ];
• Use the PATH env var. Search for the prog file in PATH dirs.
  int execlp(file, arg0 [ , arg1,... , argn ] (char *)0) char *file, *arg0, *arg1, ..., *argn;
  int execvp(file, argv) char *file, *argv[ ];
• All exec() family is the frontend of
  int execv(file, argv, envp) char *file, *argv[ ], *envp[ ];
• Example:

Program one.c :

• 
  

char *argv[ ]={"two", "abc", "123", '\0'};

char *env[]={"X=100", "Y=200", '\0'};

mail() {

printf("Running one\n");

if (execve("/usr/home/qli/two", argv, env) <= 0 ) {

perror("Can't execl"); }

}

Program two.c :

main(argv, argv)

int argc; char *argv[]; {

char *getenv( ); int i;

printf("Running two\n");

for (I=0; I< I++) printf("%s\n", argv[i]);

printf("%s, %s, %s, %s\n", getenv("X") getenv("Y"), getenv("HOME"), getenv("PWD")); }

%two # running two from shell

Running two

two

(null), (null), /usr/home/qli, /usr/home/qli

%one # running one from shell

Running one

Running two

two

abc

123

100, 200, (null), (null)

dup(int filedesc) duplicates the file descriptor to the lowest unused file descriptor number.

• Example:

#define Read 0

#define Write 1

#define STDIN 0

#define STDOUT 1

main ( ) {

FILE *fpt, *fpw;

int pfd[2]; /* pipe */

pipe(pfd);

if ((pid=fork()) != 0) { /* parent proc */

• 
  

close(STDOUT);

dup(pfd([Write]);

close(pfd[Write]);

close(pfd[Read]);

….. some code, maybe execl();

} else { /* child process */

close(STDIN);

dup(pfd([Read]);

close(ptd[Read]);

close(pfd[Write]);

…. some code, maybe execl();

} /* if */

} /* main */

pipe (conti.)

• Use fdopen with pipe

#include <.h>

#define ERROR -1

main() {

FILE *fdopen(), *fr, *fw;

int pid, pfd[2];

int i, n;

pipe(pfd);

if ((pid=fork()) == ERROR) {

printf("Can't fork\n"); exit(1); }

else if (pid != 0) { /* dad process */

fw = fdopen(pfd[1], "w");

for (i=1; i<=10; i++)

fprintf(fw, "%d\n", i);

fclose(fw);

exit(0);

} else

{ /* son process */

• 
  

fr = fdopen(pfd[0], "r");

for (i=10; i? i++) {

fscanf(fr, "%d", &n);

printf("In son process: %d\n", n);

}

fclose(fr);

exit(0);

} /* if … else */

} /* main */

-->

[Aug 20, 2004] Manipulating Files And Directories In Unix Copyright (c) 1998-2002 by guy keren.

The following tutorial describes various common methods for reading and writing files and directories on a Unix system. Part of the information is common C knowledge, and is repeated here for completeness. Other information is Unix-specific, although DOS programmers will find some of it similar to what they saw in various DOS compilers. If you are a proficient C programmer, and know everything about the standard I/O functions, its buffering operations, and know functions such as fseek() or fread(), you may skip the standard C library I/O functions section. If in doubt, at least skim through this section, to catch up on things you might not be familiar with, and at least look at the standard C library examples.

This document is copyright (c) 1998-2002 by guy keren.

The material in this document is provided AS IS, without any expressed or implied warranty, or claim of fitness for a particular purpose. Neither the author nor any contributers shell be liable for any damages incured directly or indirectly by using the material contained in this document.

permission to copy this document (electronically or on paper, for personal or organization internal use) or publish it on-line is hereby granted, provided that the document is copied as-is, this copyright notice is preserved, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

Permission to make translations of this document is also granted, under these terms - assuming the translation preserves the meaning of the text, the copyright notice is preserved as-is, and a link to the original document is written in the document's body, or in the page linking to the copy of this document.

For any questions about the document and its license, please contact the author.

Advanced Programming in the UNIX(R) Environment

A rarity - a great computer book., April 24, 2001   Reviewer: Bowen Simmons (see more about me) from Sunnyvale, CA USA The computer industry is notable for the huge quantity of really bad books it engenders. This, however, is not one of those books - this is a great book. Before explaining why it is great, I'd like to get the table of contents out of the way, so that you will know what it covers: Preface 1. Introduction (a "whirlwind tour of Unix") 2. Unix Standardization and Implementations 3. File I/O 4. Files and Directories 5. Standard I/O Library 6. System Data Files and Information 7. The Environment of a Unix Process 8. Process Control 9. Process Relationships 10. Signals 11. Terminal I/O 12. Advanced I/O 13. Daemon Processes 14. Interprocess Communication 15. Advanced Interprocess Communication 16. A Database Library 17. Communicating with a PostScript Printer 18. A Modem Dialer 19. Pseudo Terminals Appendices A. Function Prototypes B. Miscellaneous Source Code (all source code is available for download) C. Solutions to Selected Exercises Bibliography Index The first thing to understand about the book is that while it can be used as just a reference work (the index is wonderful), it really is a book you can and should read. Even if you think you know a lot of this stuff, you can be surprised at what you can still learn. What makes the book so much more useful than just a collection of man-page print-outs (that dreary and painfully common form of UNIX "book") is the method of presentation. Stevens' basic atom of organization is the function call. For each call (or minor variations on a single call), he provides the C prototype, and then, in text, explains what the function does, what it's arguments are for, and then typically provides a small C program that demonstrates it in action, which he then explains. These function-level building blocks are arranged into related sets, each of which is a chapter in the book. Each chapter has a wrapper that consists of an introduction explaining some basic concepts and history of the functions described in that chapter, and some review exercises at the end. The chapters themselves are arranged so that the earlier chapters describe the basic functions, and the later chapters describe the more difficult functions. Every chapter both teaches the reader something of immediate use in writing code (even the introduction has sample programs), as well as preparing him for the more difficult subjects that lie ahead. Now for the caveats. Stevens absolutely assumes that you know how to program in C and that you know how to use Unix development tools (or at least that you have some other source from which to learn them). This is not the book to learn how to use C or particular shells, editors, compilers, linkers, or debuggers. Similarly, new Unix variants, such as Linux and MacOS X, receive no specific mention here at all (though the book is invaluable for both). Also, there is no discussion of the various GUI interfaces offered on many current Unix systems - for those, some other book will necessary. One other thing worth mentioning is the cost of the book. Don't be put off by it - Stevens' book has been justifying that cost for a lot of readers for a lot of years. In closing, I've been a developer for many years and have owned many computer books. I recommend very few of them, but can't recommend this one highly enough. It is one of the few books I've had that routinely lies open beside me when I work. In addition to my personal recommendation, you might look not only at all the positive reviews for this book, but also at the reviews for "competitive" books and notice how often they refer you back to this one. This book is the standard by which other UNIX programming books are measured, and so far, it has not been surpassed

Using Unix System Calls by M. Rochkind, W.Toomey

• Using the C Compiler and Debugger
• An Introduction to the C Language
• Introduction to Unix System Calls
• Processes
• File I/O
• Memory Management
• Unix Signals
• More File I/O
• Pipes
• Semaphores and Shared Memory
• Security

Programming in C  --    David Marshall 1994 Contains a lot of useful info on system calls 

UNIX and C

• Advantages of using UNIX with C
• Using UNIX System Calls and Library Functions
• File and Directory Manipulation
  • Directory handling functions
  • File Manipulation Routines
  • errno
• Process Control and Management
  • Running UNIX Commands from C
    • execl()
    • fork()
    • wait()
    • exit()
  • Piping in a C program
    • popen() - Formatted Piping
    • pipe() - Low level Piping
  • Interrupts and Signals
    • Sending Signals - kill()
    • Receiving signals - signal()
• Times Up!!
• Exercises

BSD Sockets: A Quick & Dirty Primer
 

``As you delve into the mysteries of UNIX, you find more and more things that are difficult to understand immediately. One of these things, at least for most people, is the BSD socket concept. This is a short tutorial that explains what they are, how they work, and gives sample code showing how to use them.'' --Jim Frost
 

UNIX Signals and Process Groups
 

``This document describes the four common UNIX signalling environments, including their interfaces, and contrasts each. In addition, it describes the concepts and interfaces behind both BSD and POSIX process groups.'' --Jim Frost
 

Berkeley UNIX^® System Calls and Interprocess Communication
 

The purpose of this paper is to discuss interprocess communication in the context of Berkeley UNIX. Special emphasis will be given to those system calls concerned with the creation, management, and use of sockets. --Lawrence Besaw

 

Papers from the 4.4BSD PSD Manual ( Copyright Notice .)

Introductory 4.4BSD IPC (HTML)
An Advanced 4.4BSD IPC Tutorial (HTML)
 

Unix FAQ

ftp://rtfm.mit.edu/pub/usenet/news.answers/unix-faq/

 

UNIX Referance Desk

http://www.geek-girl.com/unix.html

Unix Seventh Edition Manual This is a classic. See vol1/man2.bun - system calls for historical information that may help to understand Unix kernel evolution.

Syscall specifications of Linux - Table of Contents by Louis-Dominique Dubeau.

[Beej's Guide] A fork() primer   -- From Beej's Guide to Unix Interprocess Communication

[Dubeau] Syscall specifications of Linux - Table of Contents by Louis-Dominique DubSyscall specifications of Linux - Table of Contents by Louis-Dominique Dubeau.

• Introduction
  • Conventions
• File system subsystem
  • access
  • chdir and fchdir
  • chmod and fchmod
  • chown and fchown
  • chroot
  • close
  • creat and open
  • dup and dup2
  • fcntl
  • fstat, stat and lstat
  • fstatfs and statfs
  • fsync
  • ftruncate and truncate
  • ioctl
  • link
  • lseek
  • mkdir
  • mknod
  • mount and umount
  • pipe
  • read
  • readdir
  • readlink
  • rename
  • rmdir
  • select
  • symlink
  • sync
  • umask
  • unlink
  • utime
  • write
• Virtual memory subsystem
  • brk
  • getpagesize
  • mmap and munmap
• Network subsystem
  • accept
  • bind
  • connect
  • getdomainname and setdomainname
  • gethostid and sethostid
  • gethostname and sethostname
  • getpeername
  • getsockname
  • getsockopt
  • listen
  • recv, recvfrom and recvmsg
  • send, sendmsg and sendto
  • shutdown
  • socket
  • socketpair
• Processus control subsystem
  • _exit
  • execve
  • template
  • getegid and getgid
  • geteuid and getuid

[Beej's Guide] A fork() primer   -- From Beej's Guide to Unix Interprocess Communication

• exit()
• fork()
• ps
• signal()
• signal listing
• wait()
• waitpid()

UNIX Kernel Source Tour

Tour of the Linux kernel source

The Linux Kernel -- free book by David A Rusling. One of the best source of information about Linux kernel

• Title Page
• Preface
• Hardware Basics
• Software Basics
• Memory Management
• Processes
• Interprocess Communication Mechanisms
• PCI
• Interrupts and Interrupt Handling
• Device Drivers
• The File System
• Networks
• Kernel Mechanisms
• Modules
• The Linux Kernel Sources
• Linux Data Structures
• The Alpha Processor
• Useful Web and FTP Sites
• The GNU General Public License
• Glossary

Berkeley UNIX System Calls and Interprocess Communication

The Linux Programmer's Guide, version 0.4 by B. Scott Burkett, Sven Goldt, John D. Harper, Sven van der Meer and Matt Welsh, is available in HTML, HTML (tared and gziped), LaTeX source, PDF and PostScript.

• Contents
• 1 The Linux operating system
• 2 The Linux kernel
• 3 The Linux libc package
• 4 System calls
• 5 The ``swiss army knife'' ioctl
• 6 Linux Interprocess Communications
  • 6.1 Introduction
  • 6.2 Half-duplex UNIX Pipes
    • 6.2.1 Basic Concepts
    • 6.2.2 Creating Pipes in C
    • 6.2.3 Pipes the Easy Way!
    • 6.2.4 Atomic Operations with Pipes
    • 6.2.5 Notes on half-duplex pipes:
  • 6.3 Named Pipes (FIFOs - First In First Out)
    • 6.3.1 Basic Concepts
    • 6.3.2 Creating a FIFO
    • 6.3.3 FIFO Operations
    • 6.3.4 Blocking Actions on a FIFO
    • 6.3.5 The Infamous SIGPIPE Signal
  • 6.4 System V IPC
    • 6.4.1 Fundamental Concepts
      • IPC Identifiers
      • IPC Keys
      • The ipcs Command
      • The ipcrm Command
    • 6.4.2 Message Queues
      • Basic Concepts
      • Internal and User Data Structures
      • SYSTEM CALL: msgget()
      • SYSTEM CALL: msgsnd()
      • SYSTEM CALL: msgctl()
      • msgtool: An interactive message queue manipulator
    • 6.4.3 Semaphores
      • Basic Concepts
      • Internal Data Structures
      • SYSTEM CALL: semget()
      • SYSTEM CALL: semop()
      • SYSTEM CALL: semctl()
      • semtool: An interactive semaphore manipulator
      • semstat: A semtool companion program
    • 6.4.4 Shared Memory
      • Basic Concepts
      • Internal and User Data Structures
      • SYSTEM CALL: shmget()
      • SYSTEM CALL: shmat()
      • SYSTEM CALL: shmctl()
      • SYSTEM CALL: shmdt()
      • shmtool: An interactive shared memory manipulator
• 7 Sound Programming
  • 7.1 Programming the internal speaker
  • 7.2 Programming a sound card
• 8 Character Cell Graphics
  • 8.1 I/O Function in libc
    • 8.1.1 Formatted Output
    • 8.1.2 Formatted Input
  • 8.2 The Termcap Library
    • 8.2.1 Introduction
    • 8.2.2 Find a Terminal Description
    • 8.2.3 Look at a Terminal Description
    • 8.2.4 Termcap Capabilities
      • Boolean Capabilities
      • Numeric Capabilities
      • String Capabilities
  • 8.3 Ncurses - Introduction
  • 8.4 Initializing
  • 8.5 Windows
  • 8.6 Output
    • 8.6.1 Formatted Output
    • 8.6.2 Insert Characters/Lines
    • 8.6.3 Delete Characters/Lines
    • 8.6.4 Boxes and Lines
    • 8.6.5 Background Character
  • 8.7 Input
    • 8.7.1 Formated Input
  • 8.8 Options
    • Output Options
    • 8.8.1 Input Options
    • 8.8.2 Terminal Attributes
    • 8.8.3 Use Options
  • 8.9 Clear Window and Lines
  • 8.10 Updating the Terminal
  • 8.11 Video Attributes and Color
  • 8.12 Cursor and Window Coordinates
  • 8.13 Scrolling
  • 8.14 Pads
  • 8.15 Soft-labels
  • 8.16 Miscellaneous
  • 8.17 Low-level Access
  • 8.18 Screen Dump
  • 8.19 Termcap Emulation
  • 8.20 Terminfo Functions
  • 8.21 Debug Function
  • 8.22 Terminfo Capabilities
    • 8.22.1 Boolean Capabilities
    • 8.22.2 Numbers
    • 8.22.3 Strings
  • 8.23 [N]Curses Function Overview
• 9 Programming I/O ports
  • 9.1 Mouse Programming
  • 9.2 Modem Programming
  • 9.3 Printer Programming
  • 9.4 Joystick Programming
• 10 Porting Applications to Linux
  • 10.1 Introduction
  • 10.2 Signal handling
    • 10.2.1 Signals under SVR4, BSD, and POSIX.1
    • 10.2.2 Linux signal options
    • 10.2.3 signal under Linux
    • 10.2.4 Signals supported by Linux
  • 10.3 Terminal I/O
  • 10.4 Process information and control
    • 10.4.1 kvm routines
    • 10.4.2 ptrace and the /proc filesystem
    • 10.4.3 Process control under Linux
  • 10.5 Portable conditional compilation
  • 10.6 Additional Comments
• 11 Systemcalls in alphabetical order
• 12 Abbreviations
• About this document ...

Linux Memory Management

Open Group Search Engine

http://www.opengroup.org/onlinepubs/7908799/

GNU C Library

libc -- GNU C Library - GNU Project - Free Software Foundation (FSF)

Any Unix-like operating system needs a C library: the library which defines the ``system calls'' and other basic facilities such as malloc.

The history of Unix and various standards determine much of the interface of the C library. In general the GNU C library supports the ISO C and POSIX standards. We also try to support the features of popular Unix variants (including BSD and System V) when those do not conflict with the standards. Different compatibility modes (selectable when you compile an application) allow the peaceful coexistence of compatibility support for different varieties of Unix.

Etc

FreeCode Free Programming Source Code

Socket Programming Guide

UNIX Socket Programming in C -- Programming UNIX Sockets in C - Frequently Asked Questions Created by Vic Metcalfe, Andrew Gierth and other contributers May 21, 1998

W. Richard Stevens home page

• Source code from Advanced Programming in the UNIX Environment
• Here is an updated version of the Linux source code, supplied by a reader, that supposedly works under RedHat 5.0 and 5.1.

FreeCode

UKUUG Home Page

• UK Linux Links

Last modified: February 28, 2008