Project 2: User ProgramsCS140 - Spring 2010Slides by Andrew He, adapted from previous CS140 offeringsOverview• Project 2 is due Monday, May 3, 10 pm• This project requires an understanding of:• How user programs run in general• Distinctions between user and kernel virtual memory• The system call infrastructure / file system interfaceImportant notes• You will not be able to use the corn machinesfor this project.• Use myth or pod instead.• You can choose to build project 2 on top of yourproject 1, or start from scratch.A guiding example• What happens when a user wants to run the followingprogram in the Unix shell?myth13:~$ cp -r /usr/bin/temp .1) Shell parses user input2) Shell calls fork() and execve(“cp”, argv, env)3) cp uses file system interface to copy files4) cp may print messages to stdout5) cp exits• These interactions require system callsSyscall handler• Recall: syscallsprovide theinterfacebetween a userprocess and theOS.• Popular syscalls:open, read,write, wait, exec,exit…User programs in Pintosthreads/init.c• main() => run_actions(argv) after booting• run_actions => run_task(argv)• the task to run is argv[1]• run_task => process_wait(process_execute(task))userprog/process.c• process_execute creates a thread that runsstart_process(filename…) => load(filename…)• load sets up the stack, data, and code, as well as thestart addressVirtual memory layout• Virtual memory is dividedbetween user and kernelvirtual memory.• Each user process has its ownmapping of user virtualaddresses (the pagedirectory).• User processes are notallowed to access kernelmemory or unmapped uservirtual addresses• This causes page faults• The kernel can also page faultif it accesses an unmappeduser virtual addressUser stackUninitialized dataInitialized dataCode segmentKernel virtual memory4 GBPHYS_BASE0128 MBUser virtualmemoryProject 2 requirementsYou will need to implement the following:• Passing command-line arguments to programs• Safe memory access• A set of system calls• Long list, in section 3.3.4 of the Pintos docs• Process termination messages• Denying writes to files in use as executablesArgument passing• Before a user program starts executing, the kernelmust push the functionʼs arguments onto the stack.• This involves breaking the command-line input intoindividual words.• Consider “/bin/ls -l foo bar” =>“/bin/ls”, “-l”, “foo”, “bar”• Implement the string parsing however you like• docs say to extend process_execute() to do this, but you mayplace the logic anywhere during the loading of a user program(see setup_stack())• one solution is to use strtok_r() in lib/string.cArgument passing (cont.)• Push the words ontothe stack• Push a null pointersentinel• Push the address ofeach word in right-to-left order• Push argv and argc• Push 0 as a fake returnaddress• hex_dump() function in<stdio.h> may beuseful for seeing thelayout of your stack“bar\0”“foo\0”“-l\0”“/bin/ls\0”0 (sentinel)argv[3]argv[2]argv[1]argv[0]argv4 (argc)0 (fake RA)/bin/ls -lfoo barargc = 4 stack pointerSafe memory access• The kernel will often access memory throughuser-provided pointers• These pointers can be problematic:• null pointers, pointers to unmapped user virtualmemory, or pointers to kernel addresses• If a user process passes these to the kernel, youmust kill the process and free its resources (locks,allocated memory)• Be aware of potential problems with buffers,strings, and pointersSafe memory access (cont.)Two approaches to solving this problem:• Verify every user pointer before dereference (simpler)• Is it in the userʼs address space, i.e. below PHYS_BASE? (lookat is_user_vaddr in threads/vaddr.h)• Is it mapped or unmapped? (look at pagedir_get_page() inuserprog/pagedir.c)• These checks apply to buffers / strings as well• Modify fault handler in userprog/exception.c• Only check that a user pointer is below PHYS_BASE• Invalid pointers will trigger a page fault• Better performance, takes advantage of hardware MMU• See 3.1.5 [Accessing User Memory] for more detailsSystem calls• Implement syscall_handler() in syscall.c• What does this involve?• Read syscall number at stack pointer• SP is accessible as “esp” member of the struct intr_frame *fpassed to syscall_handler()• Read some number of arguments above the stackpointer, depending on the syscall• Dispatch to the desired function• Return the value to the user in f->eax• Avoid excessive code duplication inimplementing the handlerSystem calls and filesys• Syscall numbers are defined in lib/syscall-nr.h• You will not be implementing all the calls -- see 3.3.4 [SystemCalls] for a list of required calls for Project 2• Many of the syscalls involve file system functionality• A simple filesys implementation is provided (you do NOT needto modify this, but familiarize yourself with the interfaces infilesys.h and file.h)• The file system is not thread-safe• Use coarse synchronization to ensure that any file system code isa critical section• Syscalls take “file descriptors” as arguments, but the Pintos filesystem uses struct file *s• You must design a proper mapping schemeSystem calls and filesys (cont.)• Reading from the keyboard and writing to the consoleare special cases with special file descriptors• “write” syscall with fd STDOUT_FILENO• Use putbuf(…) or putchar(…) in lib/kernel/console.c• “read” syscall with fd STDIN_FILENO• Use input_getc(…) in devices/input.hSystem calls for processes• int wait (pid_t pid)• caller blocks until the child process corresponding to pid exits• use synchronization primitives rather than thread_block()• returns the exit status of the child or -1 in certain cases• if wait has already been successfully called on the child• if pid does not reference a child of the caller• many cases to think about: multiple waits, nested waits, etc.• suggestion: implement process_wait(), and then wait() on top ofprocess_wait()• involves the most work of all the syscalls• void exit (int status)• terminate user program, return status to the kernel• print a termination message• if a child is exiting, communicate exit status back to the parent whocalled waitSystem calls for processes• pid_t exec (const char *cmd_line)• behaves like Unixʼs fork() + execve(…)• creates a child process running the program in cmd_line• must not
View Full Document
Unlocking...