- Can I cast a
struct file *to get a file descriptor? Can I cast a
struct thread *to a
- Can I set a maximum number of open files per process?
- What happens when an open file is removed?
- How can I run user programs that need more than 4KB of stack space?
- What should happen if an
execfails midway through loading?
You will have to make these design decisions yourself. Most operating systems do distinguish between file descriptors (or pids) and the addresses of their kernel data structures. You might want to give some thought as to why they do so before committing yourself.
It is better not to set an arbitrary limit. You may impose a limit of 128 open files per process, if necessary.
You should implement the standard Unix semantics for files. That is, when a file is removed any process which has a file descriptor for that file may continue to use that descriptor. This means that they can read and write from the file. The file will not have a name, and no other processes will be able to open it, but it will continue to exist until all file descriptors referring to the file are closed or the machine shuts down.
You may modify the stack setup code to allocate more than one page of stack space for each process. This is not required in this project.
exec should return
-1 if the child process fails to load for any reason. This includes the case where the load fails part of the way through the process (e.g. where it runs out of memory in the
multi-oom test). Therefore, the parent process cannot return from the
exec system call until it is established whether the load was successful or not. The child must communicate this information to its parent using appropriate synchronization, such as a semaphore, to ensure that the information is communicated without race conditions.