The Process Table (PT) contains an entry for each process present in the system. The entry is created when the process is created by a Fork system call. Each entry contains several fields that stores all the information pertaining to a single process. The maximum number of entries in PT (which is maximum number of processes allowed to exist at a single point of time in eXpOS) is MAX_PROC_NUM. In the current version of eXpOS, MAX_PROC_NUM = 16.
Each entry in the Process Table has a constant size, defined by the PT_ENTRY_SIZE. In this version of eXpOS, PT_ENTRY_SIZE is set to 16 words. Any entry of PT has the following fields:
|Field Name||TICK||PID||PPID||USERID||STATE||SWAP FLAG||INODE INDEX||INPUT BUFFER||MODE FLAG||USER AREA SWAP STATUS||USER AREA PAGE NUMBER||KERNEL STACK POINTER (KPTR)||USER STACK POINTER (UPTR)||PTBR||PTLR|
Invalid entries are represented by -1.
Note1: In this version of eXpOS, the Per-Process Resource Table is stored in the user area of each process. Generally, the Per-Process Resource Table is stored somewhere in memory and a pointer to the table is kept in the Process Table entry.
Note2: The Process Table is present in page 56 of the memory (see Memory Organisation), and the SPL constant PROCESS_TABLE points to the starting address of the table. PROCESS_TABLE + PID*16 gives the begining address of process table entry corresponding to the process with identifier PID.
The tuple can take the following values
Process states and transitions can be viewed here.
Note: When a process terminates, the STATE field in it's process table entry is marked TERMINATED to indicate that the process table entry is free for allocation to new processes.
The Per-Process Page Table contains information regarding the physical location of the pages of a process. Each valid entry of a page table stores the physical page number corresponding to each logical (virtual) page associated with the process. The logical page number can vary from 0 to MAX_PROC_PAGES- 1 for each process. Therefore, each process has MAX_NUM_PAGES entries in the page table. The address of Page Table of the currently executing process is stored in PTBR of the machine and length of the page table is stored in PTLR. In this version of eXpOS, MAX_NUM_PAGES is set to 10, hence PTLR is always set to 10.
Associated with each page table entry, typically auxiliary information is also stored. This is to store information like whether the process has write permission to the page, whether the page is dirty, referenced, valid etc. The exact details are architecture dependent. The eXpOS specification expects that the hardware provides support for reference, valid and write bits. (See page table structure of XSM here).
|PHYSICAL PAGE NUMBER||REFERENCE BIT||VALID BIT||WRITE BIT|
Note1: In the XSM machine, the first three bits of the second word stores the reference bit, valid bit and the write permission bit. The fourth bit is the dirty bit which is not used by eXpOS. For more information, see XSM.
Note2: In the eXpOS implementation on the XSM architecture, if a page is not loaded to the memory, but is stored in a disk block, the disk block number corresponding to the physical page number is stored in the disk map table of the process. If memory access is made to a page whose page table entry is invalid, a page fault occurs and the machine transfers control to the Exception Handler routine, which is responsible for loading the correct physical page.
Note3: The Page Table is present in page 58 of the memory (see Memory Organisation), and the SPL constant PAGE_TABLE_BASE points to the starting address of the table. PAGE_TABLE_BASE + PID*20 gives the begining address of page table entry corresponding to the process with identifier PID.
The per-process Disk Map Table stores the disk block number corresponding to the pages of each process. The Disk Map Table has 10 entries for a single process. When the memory pages of a process are swapped out into the disk, the corresponding disk block numbers of those pages are stored in this table. It also stores block numbers of the code pages of the process.
The entry in the disk map table entry has the following format:
|Unused||Unused||Heap 1 in disk||Heap 2 in disk||Code 1 in disk||Code 2 in disk||Code 3 in disk||Code 4 in disk||Stack Page 1 in disk||Stack Page 2 in disk|
If a memory page is not stored in a disk block, the corresponding entry must be set to -1.
Note1: The Disk Map Table is present in page 58 of the memory (see Memory Organisation), and the SPL constant DISK_MAP_TABLE points to the starting address of the table. DISK_MAP_TABLE + PID*10 gives the begining address of disk map table entry corresponding to the process with identifier PID.
Corresponding to each user process, the kernel maintains a seperate memory region (called the user area) for its own purposes. The present version of eXpOS allocates one memory page per process as the user area. A part of this space is used to store the per process resource table of the process. The rest of the memory is alloted for the kernel stack of the process. Hence in eXpOS, each process has a kernel stack in addition to user stack. We maintain a seperate stack for the kernel operations to prevent user-level "hacks" into kernel.
The Per-Process Resource Table has 8 entries and each entry is of 2 words. The last 16 words of the User Area Page are reserved for this. For every instance of a file opened (or a semaphore acquired) by the process, it stores the index of the Open File Table (or Semaphore Table) entry for the file (or semaphore) is stored in this table. One word is used to store the resource identifier which indicates whether the resource opened by the process is a FILE or a SEMAPHORE. Open system call sets the values of entries in this table for a file.
The per-process resource table entry has the following format.
|Resource Identifier (1 word)||Index of Open File Table/ Semaphore Table entry (1 word)|
File descriptor, returned by Open system call, is the index of the per-process resource table entry for that open instance of the file.
A free entry is denoted by -1 in the Resource Identifier field.
Control is tranferred from a user program to a kernel module on the occurence of one of the following events :
In the case of a system call, the application will store the parameters for the system call in its user stack. Upon entering the kernel module (system call), the kernel will extract these parameters from the application's stack and then change the stack pointer to its own stack before further execution. Since the application invokes the kernel module voluntarily, it is the responsibility of the application to save the contents of its registers (except the stack pointer and base pointer registers in the case of the XSM machine) before invoking the system call.
In the case of an interrupt/exception, the user process does not have control over the transfer to the kernel module (interrupt/exception handler). Hence the execution context of the user process (that is, values of the registers) must be saved by the kernel module, before the kernel module uses the machine registers for other purposes, so that the machine state can be restored after completion of the interrupt/exception handler. The kernel stack is used to store the execution context of the user process. This context is restored before the return from the kernel module. (For the implementation of eXpOS on the XSM architecture, the backup and restore instructions facilitate this).
In addition to the above, if a kernel module invokes another kernel module while executing a system call/interrupt, the parameters to the called module and the return values from the module are passed through the same kernel stack.
Here is a detailed tutorial on kernel stack management in system calls, interrupts and exceptions. A separate tutorial is provided for kernel stack managament during context switch.