the sstem-call interface.pptVIP

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. 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! 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 for calls to these ‘external’ library-functions. C program example revised(we’ve omitte