Note that children are not inherited: if A spawns child B and B spawns child process C, then A cannot wait for C, even if B is dead. pid is a direct child of the calling process if and only if the calling process received pid as a return value from a successful call to exec. Pid does not refer to a direct child of the calling process. Wait must fail and return -1 immediately if any of the following conditions is true: It is perfectly legal for a parent process to wait for child processes that have already terminated by the time the parent calls wait, but the kernel must still allow the parent to retrieve its child's exit status, or learn that the child was terminated by the kernel. killed due to an exception), wait(pid) must return -1. If pid did not call exit(), but was terminated by the kernel (e.g. Then, returns the status that pid passed to exit. If pid is still alive, waits until it terminates. Waits for a child process pid and retrieves the child's exit status. You must use appropriate synchronization to ensure this.
Thus, the parent process cannot return from the exec until it knows whether the child process successfully loaded its executable. Must return pid -1, which otherwise should not be a valid pid, if the program cannot load or run for any reason. Runs the executable whose name is given in cmd_line, passing any given arguments, and returns the new process's program id (pid). System Call: pid_t exec (const char *cmd_line).Conventionally, a status of 0 indicates success and nonzero values indicate errors. If the process's parent waits for it (see below), this is the status that will be returned. Terminates the current user program, returning status to the kernel. This should be seldom used, because you lose some information about possible deadlock situations, etc. Terminates Pintos by calling shutdown_power_off() (declared in threads/init.h).
(This header, and all others in lib/user, are for use by user programs only.) System call numbers for each system call are defined in lib/syscall-nr.h: The prototypes listed are those seen by a user program that includes lib/user/syscall.h. It will need to retrieve the system call number, then any system call arguments, and carry out appropriate actions. The skeleton implementation we provide "handles" system calls by terminating the process. Implement the system call handler in userprog/syscall.c.
PINTOS PROJECT2 ARGUMENT PASSING CODE
Two methods to handle invalid memory access Verify the validity of user provided pointer and then dereference it Look at functions in userprog/pagedir.c, threads/vaddr.h Strongly recommended! Check if user pointer is below PHYS_BASE and dereference it Could cause page fault Handle the page fault by modifying the page_fault() code in userprog/exception.c Make sure that resources are not leaked There could be 2 methods to handle invalid memory access.
PINTOS PROJECT2 ARGUMENT PASSING HOW TO
Why? Kernel has access to all of physical memory including that of other processes Kernel like user process would fault when it tries to access unmapped addresses User process cannot access kernel virtual memory User Process after it has entered the kernel can access kernel virtual memory and user virtual memory How to handle invalid memory access? In C, a user program test.c can pass argument int main(int argc, char* argv) Timer Interrupts Other IRQs User Programs Kernel int 0x30 Exceptions Project 2 Tests Project 1 lib/user/syscall.c filesystem syscall layer exc handling But in project2, the user program could call various system calls which would then be processed by the kernel When user programs are run, we have some issues like managing the memory and loading different user programs and scheduling them appropriately In project1, since the code was compiled directly with kernel, it required that we call some kernel specific functions. Presented by Xiaomo Liu (update Min Li’s slides)Ģ Till now … All code part of Pintos KernelĬode compiled directly with the kernel This required that the tests call some functions whose interface should remain unmodified From now on, run user programs on top of kernel Freedom to modify the kernel to make the user programs work In project1, all the changes run as part of the kernel but in project 2, it would not be entirely so.
0 kommentar(er)
