Transcript The OS 215 Project

The OS 215 Project
OS 215 Project Outline
•
•
•
•
Architecture of the Simulator Environment
Z215 Hardware Organization and Architecture
Generic Operating System Structure
The Test Suite
– Phase 0 Tests
– Phase 1 Tests
– Phase 2 Tests
2
Simulator Environment
OS 215 Test Suite (test.c)
test0
test1a
test1b
test1x
test2a
OS 215 Operating System
(base.c, scheduler_printer.c)
Z215 Hardware Simulator
(z215.c)
test2b
...
All elements inside the heavy box are in
a single process, running a single thread
of execution.
All I/O devices of the Z215 are simulated
entities. This includes the timer device
and the disk devices.
Try to treat the Z215 Hardware Simulator
as a “black box” and use the Z215 architecture
specification instead.
Native Operating System
(Windows NT, HP-UX, Solaris, etc.)
Native Hardware Platform
(IA-32, PA-RISC, Sun Workstation, etc.)
Look at the Addendum to get lots of other nice pictures of this layout.
3
Z215 Architecture
• Dual-Mode architecture
– User mode (see A.4)
• High level language, augmented with
– Z215 General Purpose Registers
– Macros for simplifying reentrant programs
– Systems Calls, provided as macros (do not rewrite!)
• Z215 “Programs” are written as C functions taking a void parameter and
having a void return.
• Example Program:
void test0( void )
{
SELECT_STEP
{
STEP( 0 )
printf(“This is test 0”);
GET_TIME_OF_DAY( &Z215_REG_1 );
STEP( 1 )
printf(“Time of day is %d\n”, Z215_REG_1);
TERMINATE_PROCESS( -1, &Z215_REG_9 );
STEP( 2 )
printf(“Error: Test should be terminated, but isn’t\n”);
break;
}
4
}
Z215 Architecture (cont.)
– User Mode (cont.)
• Address space for user programs is divided into
– C code “program” memory for instructions and for local variables. This, for all
intents and purposes, is not constrained in size.
– User “data” memory, referenced through a virtual address space, and called
MEMORY, and accessed from user space through the MEM_XXXX macros. No
programs in phase 1 access this user memory.
– Kernel Mode
• Instruction set includes C language instructions, plus
– access to all the Z215 registers
– access to Z215 physical memory (MEMORY)
– access to the privileged instructions of the Z215 instruction set
• I/O primitives
• memory primitives
• context switching primitives
– These are all available through provided macros
5
Z215 Registers and Vectors
Name
Bits
Usage
Z502_REG_ARG1 …
Z502_REG_ARG6
Z502_REG_1 …
Z502_REG_9
Z502_REG_PROGRAM_COUNTER
32
For passing system call parameter values
32
General purpose
32
Points to next location in user program
Z502_REG_PAGE_TABLE_ADDR
32
Points to page table
Z502_REG_PAGE_TABLE_LENGTH
32
Length of page table in 32 bit entries
Z502_REG_CURRENT_CONTEXT
32
Handle for current context
Z502_REG_INTERRUPT_MASK
32
Interrupt enable/disable
TO_VECTOR
3 x 32
Addresses of interruption handlers
STAT_VECTOR
2xN
x 32
Exception statuses
6
Interruption Handling by the Z215
• Interruption Sources
– Interrupts
• TIMER_INTERRUPT from the delay timer
• DISK_INTERRUPT from disk 1, 2, ...
– Faults
• INVALID_MEMORY fault
• CPU_ERROR fault
• PRIVILEGED_INSTRUCTION fault
– Traps
• SOFTWARE_TRAP for each system call
– TO_VECTOR contains an address for each category of
interruption source.
7
Interruption Handling
• In os_init (the OS boot code), the OS sets values for each
of the entries in TO_VECTOR.
• On the Z215, there is a total enumeration of all
interruptions (exceptions)
•
•
•
•
•
•
•
•
•
SOFTWARE_TRAP
CPU_ERROR
INVALID_MEMORY
PRIVILEGED_INSTRUCTION
TIMER_INTERRUPT
DISK_INTERRUPT
DISK_INTERRUPT + 1
…
LARGEST_STAT_VECTOR_INDEX
8
Z215 Hardware Actions on Interruption
• Let the interruption number (called exception in
Appendix A) be x.
• User registers are saved in Z215 Hardware Context
• Hardware sets
– STAT_VECTOR[SV_ACTIVE][x] = TRUE
– STAT_VECTOR[SV_VALUE][x] = interruption specific info
• Execution mode is set to kernel
• Hardware begins execution at Interrupt, Fault, or Trap
entry point as defined by TO_VECTOR
• Note that INTERRUPT_MASK is not set to TRUE. The
operating system must do this if that is the desired mode of
operation.
9
OS Responsibilities on an Interruption
• On Entry
– Mask interrupts (if desired)
– Clear the Interruption Source
• set STAT_VECTOR[SV_ACTIVE][x] to FALSE
– Determine the cause of the interruption and process accordingly
• On Exit
– Unmask interrupts (if not already done).
– For Interrupts, simply return
– For traps and faults, ultimately exit the OS by performing a context
switch (even if that switches back to the original process). This
operation restores the user registers from the Z215 Hardware
Context and sets the execution mode back to user.
10
Interruption Causes
• Use STAT_VECTOR[SV_VALUE][x] to determine an
interruption cause and influence processing:
– For SOFTWARE_TRAP, value is the system call number. Use this
to enter a switch statement to process system calls.
– For CPU_ERROR, value is given by error codes (see table in
Appendix A)
– For INVALID_MEMORY, value is virtual memory page causing
the fault
– For PRIVILEGED_INSTRUCTION, value is 0
– For all interrupts (timer and disk), value is given by error codes
(where one of the possibilities is ERR_SUCCESS)
11
Z215 Hardware Context
• The context is the state of the executing CPU, essentially
its registers.
• The Hardware context is essentially a register set, plus an
entry address.
• The OS only deals with the handle to a context. Typically
this is stored in the process control block.
• Z215 Operations for manipulating contexts
– Z215_MAKE_CONTEXT(handle, start address, kernel flag)
– Z215_DESTROY_CONTEXT(handle)
– Z215_SWITCH_CONTEXT(save/destroy flag, handle)
12
Operating System Structure
• Organize into functional areas
– What are the functional areas of the Operating System?
– What are the abstract data types required?
– Class participation, putting together an OS structure…
• Next steps (Milestone 3)
– Strawman functional spec for each module defined in the block
diagram.
– For each module
• set of interrelations with other OS modules
• portions of the Z215 interface being invoked by the module
• Set of system calls realized within the module
– For system calls
• Categorization by module
• Attributes: blocking vs. non-blocking, save/destroy context
13
Milestone: test0
• Code given previously. Nearly the simplest user program
possible.
• Requirements
– Core OS
• os_init
– TO_VECTOR
• trap_handler
– System call switch
– Process Management module
• os_create
• os_terminate
– Timer module
• os_get_time
14
The Test Suite: Phase 1
• Test1a: Add SLEEP, requires timer multiplexing and
interrupt handling, infrastructure for multiple processes.
• Test1b: Interface tests to CREATE_PROCESS
• Test1c: Multiple instances of test1a; demonstration of
FCFS scheduling (by using same priorities)
• Test1d: Likewise for different priorities
• Test1e: Suspend/Resume interface test
• Test1f: Suspend/Resume on real scheduling
• Test1g: Change Priority interface test
• Test1h: Change Priority on real scheduling
• Test1k: Misc. error tests
15
Components In The Starter Code
Test.c
test0 test1a test1b
ooooo oooo
test2g
O.S.
OS_
Switch_
Context_
Complete
SVC
interrupt_handler
fault_handler
OS_
Init
z215.c
August, 2004
Z215_
CLOCK
Z215_
IDLE
Z215_
DELAY_
TIMER
Z215_
SWITCH_
CONTEXT
Z215_
DESTROY_
CONTEXT
Z215_
MAKE_
CONTEXT
main
16
OS Components – What you need to Build
Test.c
O.S.
Give_Up_CPU
Ready
Queue
Dispatcher
Make_Ready_
To_Run
SVC
Start_
Device
Device
Queue
OS_
Switch_
Context_
Complete
Interrupt_Handler
OS_
Init
z215.c
August, 2004
Z215_
CLOCK
Z215_
IDLE
Z215_
DELAY_
TIMER
Z215_
SWITCH_
CONTEXT
Z215_
DESTROY_
CONTEXT
Z215_
MAKE_
CONTEXT
17
The Execution of test0
test0
test.c
5
8
9
base.c
SVC
6
z215.c
August, 2004
4
7
Z215_
CLOCK
10
OS_
Switch_
Context_
Complete
3
Z215_
HALT
switch_context
OS_
Init
2
1
main
18
The Execution of test0
1
2
3
The program starts in main(). A temporary context is created and the simulation
starts by requesting to run on that context.
os_init is a routine in the operating system. For right now, all it does is create a
context that will allow test0 to run.
We come to os_switch_context_complete before we go out to the new code in test.
Who knows what you might want to do with this!
4
We go out to test0. It is time to run the user code.
5
Test0 does a system call get_time_of_day. A system call produces a software
interrupt that causes execution to go to svc, the software service routine.
svc must get the time in order to service the system call. It calls the hardware to
do that. It passes by reference a variable in which the time can be placed.
Z215_CLOCK is a hardware routine that keeps track of the time. It passes back
this time to svc.
svc passes back the time to test0. test0 prints out that time as part of its code.
6
7
8
9
10
test0 does a terminate_process system call – it’s all done with its job. It makes this
call and again the execution ends up back in svc.
Svc must handle this terminate_process request. Eventually this code will be more
complicated, but for right now, since there’s nothing else for the OS to do, it
simply ends the simulation by halting the processor.
19
The Execution of test1
test1a
test.c
5
14
SLEEP
4
OS_
Create_Process
base.c
3
OS_
Init
6
SVC
7
13
11
Timer
Queue
Start_
Timer
2
Interrupt_Handler
10
8
z215.c
August, 2004
Z215_
CLOCK
9
Z215_
DELAY_TIMER
12
Z215_
IDLE
switch_context
1
main
20
The Execution of test1a
1
2
3
4
5
The program starts in main(). A temporary context is created and the simulation
starts by requesting to run on that context.
os_init figures out what test you want to run. It passes the identifier for that test
to os_create_process.
We come to os_create_process, a routine YOU write. Here we create the context,
create the PCB, and then call Z215_SWITCH_CONTEXT.
Os_create_process calls Z215_Switch_Context which transfers control to test1a.
Note: Test1a does various system calls, but we’re looking only at SLEEP in this
picture. Test1a does a system call SLEEP transferring control to svc.
6
svc hands control of the SLEEP request to start_timer, a routine YOU write.
7
start_timer, enqueues the PCB of the running process onto the timer_queue.
8
Start_timer calls the Z215_DELAY_TIMER to give the request for a future
interrupt. The timer starts thinking about the time, but interrupts in the future!!
Start_timer realizes there’s nothing else to do and so calls Z215_IDLE. This
routine says to idle the processor until an interrupt occurs.
Svc must handle this terminate_process request. Eventually this code will be more
complicated, but for right now, since there’s nothing else for the OS to do, it
simply ends the simulation by halting the processor.
9
10
21
The Execution of test1a
11
When the delay timer expires, an interrupt is generated. This causes the processor
to go to the interrupt handler.
In the interrupt handler, take the PCB off the timer queue. This is the process
that has been sleeping!
12
When you return from the interrupt_handler, execution returns back to
start_timer, to the line AFTER your call to Z215_IDLE.
13
Start_timer returns to svc.
10
14
svc returns to test1a.
22