The ‘system-call’ interface

We see how an application program can invoke privileged

kernel services

Recall our previous lesson

• First, we presented a (simplified) diagram of the major components in a modern OS

• Then, we focused our attention on one of the kernel’s interfaces, namely, its role in controlling hardware devices (specifically the IDE fixed disk). We saw typical code for performing an actual device-command.

• Today we look at another kernel interface.

A Modern OS Design

Hardware

Application ApplicationApplication

Shared Runtime Librariesuser-mode

supervisor-mode

System Call Interface

Device Driver Components

memorymanager

taskmanager

filemanager

networkmanager

OS Kernel

Our demo ‘bypassed’ the OS

Hardware

Application Application

Shared Runtime Librariesuser-mode

supervisor-mode

System Call Interface

Device Driver Components

memorymanager

taskmanager

filemanager

networkmanager

OS Kernel

Application(idnumber)

RequiredIOPL==3

Role of ‘runtime libraries’

• To understand what role is played by the kernel’s interface with ‘runtime libraries,’ let’s see how we could go around them.

• We can create a demo-program that does not need to use the standard C library – it will perform all their work on its own.

• If you fire your janitor, you will very quickly come to appreciate all that he did for you!

Demo will call kernel directly

Hardware

Application ApplicationApplicationdemo

Shared Runtime Librariesuser-mode

supervisor-mode

System Call Interface

Device Driver Components

memorymanager

taskmanager

filemanager

networkmanager

OS Kernel

A normal C program example

# include <unistd.h> // for write()# include <stdlib.h>// for exit()

char message[ ] = “Hello!\n”;

int main( void ){

write( 1, message, 7 );exit( 0 );

}

Standard device-files

• Whenever a new program is launched, the operating system will automatically ‘open’ three device-files, named ‘stdin’, ‘stdout’, and ‘stderr’, using file-drescriptors 0, 1, 2. – ‘stdin’ is the standard input device (keyboard)– ‘stdout’ is the standard output device (screen)– ‘stderr’ is the standard error device (screen)

Standard C library functions

• The functions ‘write()’ and ‘exit()’ were not actually defined within our program-code

• They are examples of ‘external’ functions

• Header-files let the compiler know how to generate assembler code that calls them

• Their actual definitions are part of the standard GNU/C runtime-library (‘glibc’)

• The linker connects our code to ‘glibc’

The function ‘prototypes’

int write( int fd, char * buf, int count );

void exit( int status );

The C compiler needs this information to correctly generate the machine-code forcalls to these ‘external’ library-functions.

C program example revised(we’ve omitted the header-files)

extern int write( int, char *, int );extern void exit( int );

char message[ ] = “Hello!\n”;

int main( void ){

write( 1, message, 7 );exit( 0 );

}

How these calls get compiled

pushl $7 # parameter no. 3pushl buf # parameter no. 2pushl $1 # parameter no. 1call write # call to C libraryaddl $12, %esp # discard params

pushl $0 # parameter no. 1call exit # call to C library

Stack’s layout on entering ‘write’

Parameter number 3 (count)

Parameter number 2 (buf)

parameter number 1 (fd)

Return-address (from EIP)

ESP

32-bits

What ‘write’ function does

write: pushl %ebp # save caller’s EBPmovl %esp, %ebp # point EBP to stacktop

# copy the parameters into general registersmovl $4, %eax # sys_WRITE ID-numbermovl 8(%ebp), %ebx # parameter no. 1 to EBXmovl 12(%ebp), %ecx # parameter no. 2 to ECXmovl 16(%ebp), %edx # parameter no. 3 to EDXint $0x80 # enter the linux kernel

popl %ebp # restore previous EBPret # return to the caller

What ‘exit’ function does

exit: pushl %ebp # save caller’s EBPmovl %esp, %ebp # point EBP to

stacktop

# copy the parameter into a general registersmovl $1, %eax # sys_EXIT ID-numbermovl 8(%ebp), %ebx # parameter no. 1 to

EBXint $0x80 # enter the linux

kernel

# Note: The ‘exit()’ function never returns to the application

So we don’t really need library

• If we are willing to rewrite our program using assembly language (so that we can refer to cpu registers by name), we can make system-calls directly to the kernel (using the ‘int $0x80’ trap-instruction) without needing to link our code to those shared C library functions

• Doing this helps us convince ourselves that we do indeed understand what the role of the C runtime function-library is – it’s a programming convenience (puts a pretty face on ugly code).

Program ‘portability’

• If we want a program that can be compiled and executed on machines with different CPU designs (e.g., PCs versus MACs), then we will need to avoid using register-names in our program-code (i.e., the PC’s EAX register doesn’t exist on the MAC)

• The shared library ‘hides’ the differences between CPUs, since all the CPU-specific work is done by code within the library

POSIX

• The ‘Portable Operating System Interface’

• Defines a conformance ‘standard’ that lets application programmers write code which is ‘portable’ across differing architectures

• Implemented with header-files and shared runtime libraries

• Documented as an ANSI standard

• Online reference available via ‘man’ pages

Frequently needed functions

• Here are a few of the POSIX standard functions which are most frequently used by applications:– open()– read()– write()– close()– exit()

• It’s advisable to learn them! (will save you time)

Their C function-prototypes

void exit( int status ); int read( int fd, char *buf, int count ); int write( int fd, char *buf, int count ); int open( char *fname, int flags, … ); int close( int fd );

NOTE: These POSIX functions correspond directly to Linux kernel system-calls

function semantics

• We will give a rough general description of the actions taken by the kernel when these five frequently needed functions are called

• Additional details about each function can be found online, using the ‘man’ command

• Example: $ man 2 read

int write( int fd, char *buf, int count )

• This function asks the kernel to transfer ‘count’ bytes from the array pointed to by ‘buf’ to the previously-opened file specified by the file-descriptor ‘fd’.

• If the kernel cannot transfer any bytes, it returns the value -1; otherwise it returns the number of bytes that the kernel was able to transfer successfully and advances the file-pointer accordingly.

int read( int fd, char *buf, int count )

• This function asks the kernel to transfer ‘count’ bytes into the array pointed to by ‘buf’ from the previously-opened file specified by ‘fd’.

• If the kernel cannot transfer any bytes, it returns a value of -1 -- unless the file-pointer is already at the end of the file; otherwise, it returns the number of bytes successfully transferred and advances the file-pointer accordingly.

int open( char *fname, int flags, … )

• This function asks the kernel to set up an internel record establishing a connection between the file named ‘fname’ and an unused nonnegative integer known as a file-descriptor, provided the file’s access permissions allow the kind of access that is specified by the ‘flags’ argument

• The function returns -1 if it cannot perform this operation; otherwise, it returns the file-descriptor value.

• An additional argument when creating a new file

int close( int fd );

• This function asks the kernel to remove the connection it had previously set up between the file-descriptor ‘fd’ and the internal kernel record of an associated file.

• The value -1 is returned if the kernel was not succesful in performing this operation (e.g., the file had already been closed); otherwise, this function returns 0.

void exit( int status )

• This function asks the kernel to terminate the current program, and place the value of ‘status’ into the internal record that the kernel had associated with this program when it was first launched.

• This function will not return any value (because it does not return at all!)

In-class exercises

• Modify the ‘mywrite.c’ demo (see class website) so it that writes to device 2 instead of device 1

• Try using the debugging tool to single-step through the execution of ‘filedemo’. Watch which values the kernel returns (in EAX) after each ‘int $0x80’ trap-instruction. Verify that it indeed created the ‘testfile.dat’ file.

• Write a short program (named ‘myread.c’) which uses standard C library functions to ‘read’ the ‘testfile.dat’ file and ‘write’ its contents to ‘stdout’