DOC PREVIEW
UNO CSCI 8530 - System Call Implementation

This preview shows page 1-2-3 out of 8 pages.

Save
View full document
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
View full document
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience
Premium Document
Do you want full access? Go Premium and unlock all 8 pages.
Access to all documents
Download any document
Ad free experience

Unformatted text preview:

1The Tempo Operating SystemPart 6System Call ImplementationProcesses and TimersLast edit: 10/9/2007newproca – Process CreationConceptually simple:validate parametersallocate an unused process table entryfill in the appropriate valuesallocate user and kernel stack spaceinitialize stacks for initial return from kernelNo code or data needs to be initialized, since these are already present.The most complicated part of newproca is getting the initial user and kernel stack contents correct.newproca: pseudocode (1)Find an unused process table entry; if not found, return error (PROCTBLFULL)Extract system call argumentsSetup tag, priority, and process IDAllocate user-mode stack, handle errorsDetermine size of string argumentsSet user stack info: #args, ptr to args, return address (processDone)Copy string arguments and pointers to user-mode stacknewproca: pseudocode (2)Allocate kernel-mode stack (always 1 page)Initialize kernel stack: user-mode stack segment and stack pointer, eflags register, code segment and instruction pointer, remaining segment and general-purpose registersInitialize event queues (empty, unmasked)Setup file descriptors 0/1 for keyboard, displaynewproca: pseudocode (3)Mark all other file descriptors as available for useMark process as not signaled (see signal discussion for details)Increase number of processes in systemAdd process to appropriate ready queue by calling addreadyIf new process has priority greater than current (creating) process, add current process to appropriate ready queue and set _rs to 1Return ID of the new processUser Stack at Process StartupString NString 2String 1…Addr Str NAddr Str 2Addr Str 1…Null PtrArray Addr NprocessDoneInitial stack pointerBottom of stack(return address)(argc)(argv)2Kernel Stack at Process StartupUser Stack SelUser Stack PtrUser Code SelInstr. PointerOther Segment Registers (4)Gen. Purpose Registers (8)eflags Reg.Initial kernel stack pointerBottom of the kernel stackPopped/restored by the “iret” instruction after “isr30z” in kernel.sCopy of Intr #So system call stacks look like all other interrupt stacksrun – create & load process from diskContrary to its name, newproca does not really create a process. Instead, it creates what is usually called a thread.The run system call, on the other hand, creates a “real” process and initializes its address space appropriately (code/data comes from a disk file).run – pseudocode (part 1)Find an unused process table entry; if not found, return error (PROCTBLFULL).Extract system call arguments.Expand runinf structure’s components, or copy caller’s information for new process.Validate new process priority.Allocate a page of RAM for the new process’ page table.Open the file containing the executable image.Load the executable file into RAM (described later).Close the file.run – pseudocode (part 2)Initialize the stack for the process. This is done in a manner similar to that done for newproca.Allocate a page for the kernel stack.Initialize the kernel stack.Set user/system, RW, and presence bits appropriately for the page table entries.Initialize event queues and file descriptors.Copy the environment (environ) and working directory (workdir) information to the process table entry.Add the process to the appropriate ready queue (addready), set _rs to 1 if appropriate, and return.Loading an executable file (part 1)There are two (actually three, but one is funky) forms of executable files handled by the run system call : ELF (Executable and Loadable Format) and PE (Portable Executable). ELF is most common in the Linux environment, while PE executables are used in the Windows world.Executable files contain completely linked applications packaged in multiple sections or segments, each preceded by a section header.Typical sections are those for text (code) and data.Loading an executable file (part 2)Loading takes place as follows:Validate the file format as one we can handleFor each section:• Extract information from a section header– Virtual address where the section should be loaded– Size of the section• Allocate pages of memory (real and virtual) for the section, update the page table for the process• Copy the section from disk to memorySet the program “break” (top of allocated memory)Allocate and clear a page for the process stack3addreadyThe addready function has a single parameter: a pointer to a process table entry.The state member of that process table entry is set to PROCESS_READY.The process table entry is linked (using the nextand prev members) onto the appropriate ready queue.getpid: pseudocodeGetpid almost warrants no explanation, since it only extracts and returns the pidmember of the process table entry for the current process.The only thing worth noting is that it is always assumed that the global variable activeProcesspoints to the process table entry for the running process.getpstate: pseudocodeGetpstate, like getpid, just returns the contents of a member (in this case, state) of the process table entry.For this call we must map from the pid to a pointer to the process table entry. This is done by the pid2a function (in sys.c), which just does a linear search of the entire array, returning the appropriate pointer (if the pid was found) or NULL (0) otherwise.Once the pointer is located (or not), the appropriate value is returned to the caller.getprio, getquantum, setquantumEach of these system calls just returns a field from the process table for the currently-running process and/or gets/sets the value of a global variable.No further explanation should be necessary to understand their implementation.setprio: psuedocodeVerify argument is within allowed range for process priorities; if not, return errorIf the new priority is the same as the current priority, return without changeModify the process table entryIf there now exists a ready process with a priority higher than the current process’ priority:Move the current process to the ready state by calling addreadySet _rs to 1 to force a context switchReturnyield: pseudocodeRecall that the yield system call causes the running process to voluntarily relinquish the CPU to another process at the same priority. The steps taken are:add the current process (the one yielding the CPU) to the appropriate ready queue by calling addreadyset _rs to 1 to force a context switchreturn4exit: pseudocodeExit does little “direct” work:The exitstatus member of the process table entry of the terminating


View Full Document

UNO CSCI 8530 - System Call Implementation

Download System Call Implementation
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view System Call Implementation and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view System Call Implementation 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?