The ‘system-call’ interface

1. The ‘system-call’ interface We see how an application program can invoke privileged kernel services

2. 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.

3. A Modern OS Design Application Application Application Shared Runtime Libraries user-mode supervisor-mode System Call Interface memory manager task manager file manager network manager Device Driver Components OS Kernel Hardware

4. Our demo ‘bypassed’ the OS Application (idnumber) Application Application Shared Runtime Libraries user-mode supervisor-mode System Call Interface Required IOPL==3 memory manager task manager file manager network manager Device Driver Components OS Kernel Hardware

5. 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!

6. Demo will call kernel directly Application demo Application Application Shared Runtime Libraries user-mode supervisor-mode System Call Interface memory manager task manager file manager network manager Device Driver Components OS Kernel Hardware

7. 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 ); }

8. 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)

9. 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’

10. 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.

11. 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 ); }

12. How these calls get compiled pushl $7 # parameter no. 3 pushl buf # parameter no. 2 pushl $1 # parameter no. 1 call write # call to C library addl $12, %esp # discard params pushl $0 # parameter no. 1 call exit # call to C library

13. Stack’s layout on entering ‘write’ 32-bits Parameter number 3 (count) Parameter number 2 (buf) parameter number 1 (fd) Return-address (from EIP) ESP

14. What ‘write’ function does write: pushl %ebp # save caller’s EBP movl %esp, %ebp # point EBP to stacktop # copy the parameters into general registers movl $4, %eax # sys_WRITE ID-number movl 8(%ebp), %ebx # parameter no. 1 to EBX movl 12(%ebp), %ecx # parameter no. 2 to ECX movl 16(%ebp), %edx # parameter no. 3 to EDX int $0x80 # enter the linux kernel popl %ebp # restore previous EBP ret # return to the caller

15. What ‘exit’ function does exit: pushl %ebp # save caller’s EBP movl %esp, %ebp # point EBP to stacktop # copy the parameter into a general registers movl $1, %eax # sys_EXIT ID-number movl 8(%ebp), %ebx # parameter no. 1 to EBX int $0x80 # enter the linux kernel # Note: The ‘exit()’ function never returns to the application

16. 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).

17. 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

18. 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

19. 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)

20. 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

21. 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

22. 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.

23. 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.

24. 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

25. 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.

26. 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!)

27. 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’