Appendix D

Scheduler Printer And Output Philosophy

1. Using The Scheduler Printer

1.1 Introduction

This tool is designed to save you time by giving a simple way to print out nicely formatted information about the state of the processes on your system. It should, perhaps, more aptly be named "process_printer". To use the printer, you repetitively do the following:

1. Call SP_setup multiple times, defining information about what the scheduler is doing and the state of the various processes on the system.
2. Call SP_print_line which has the effect of dumping out all the data you've just defined using SP_setup. You can optionally call SP_print_header at any time to make a pretty header line.

The ultimate goal is to have a simple and compact way to display what the scheduler and various processes are doing at any point in time.

1.2 Using SP_setup

Format: SP_setup( mode, data );

SP_setup is called in order to define the various items that will be printed. It is called with many different modes, the general format being SP_setup( mode, data ); mode is one of the mnemonics described below. Data can be any of the following three types:

1. SP_FILE_MODE assumes a pointer to a type FILE

FILE *file_ptr;
SP_setup_file( SP_FILE_MODE, file_ptr );

2. SP_ACTION_MODE assumes a pointer to a string is being passed.

char action[SP_LENGTH_OF_ACTION];
SP_setup_action( SP_ACTION_MODE, action );

3. ALL OTHER modes assume that a long value is being passed.

long current_time;
SP_setup( SP_TIME_MODE, current_time );

Here are the various modes, and a brief description of how they are used.

1. SP_FILE_MODE: Use this mode to define the file pointer where the output should go. If you don't ever use this mode, output goes to the console.
2. SP_ACTION_MODE: This wants a pointer to a string which contains a maximum of 8 characters describing what scheduler action is being performed.
3. SP_TIME_MODE: This is an integer representing the current simulation time.
4. SP_TARGET_MODE: What is the process id on which the scheduler action is being performed.
5. SP_NEW_MODE: The process id ( number in range 0 - 99 ) of a process which is in the new state.
6. SP_RUNNING_MODE: The process id ( number in range 0 - 99 ) of a process which is in the running state.
7. SP_READY_MODE: The process id ( number in range 0 - 99 ) of a process which is in the ready state.
8. SP_WAITING_MODE: The process id ( number in range 0 - 99 ) of a process which is in the waiting state.
9. SP_SUSPENDED_MODE: The process id ( number in range 0 - 99 ) of a process which is in the suspended state.
10. SP_SWAPPED_MODE: The process id ( number in range 0 - 99 ) of a process which is in the swapped state.
11. SP_TERMINATED_MODE: The process id ( number in range 0 - 99 ) of a process which is in the done state.

NOTE: The various modes that define PIDs in states can be called multiple times per printout.

NOTE: After an SP_print_line is executed, all the state information ( except the file data ) is nullified.

1.3 Using SP_print_header

Format: SP_print_header();

This string is printed out when requested as a header:

"Time Target Action Running New DONE State Populations"

The string is defined in the include file syscalls.h.

1.4 Using SP_print_line

Format: SP_print_line();

This routine prints out all the data that has been defined using SP_setup. It also nullifies this data, initializing the printer for the next set of definitions. Here is an example of the output:

2. Printing Philosophy

The output generated from running your operating system can be overwhelming. The amount of data produced is abundant and in an effort to reduce the amount of paper you turn in, here are a few guidelines.

The output from your operating system comes in 3 categories, a) Scheduler Output, b) Output from the tests you ran, and c) Error and Trap handling. The requirements on what you are to hand in varies for each test. See the student manual for a detailed list.

Each of these categories are addressed below.

2.1 Scheduler Output

Attached is a sample output using code similar to scheduler_printer.c provided to you. This is meant to be an example, but you should use this sample as a model and provide your output in a similar format.

The scheduler has five actions that should be logged (you may have more); Dispatch, Create, Done (or Terminate), Ready, and Wait.

By adding a variable(s) to your PCB, you can control how a process is logged. In this example, only 3 Dispatches are logged for each process, subsequent dispatches are not logged. You should have a higher limit (perhaps in the 5-10 range).

All Create and Done actions are logged for each process.

A similar mechanism used for dispatch logging should be used for the Ready and Wait actions. In the example, Ready and Wait actions are not logged.

When a process is SUSPENDED or has its priority changed, you should reset your logging variable(s) in the PCB, so that these changes to the process can be seen.

You should highlight interesting things in your output, for example: if a process is suspended and resumed, or a change in priority.

2.2 Test Output

The results from all test programs should be handed in, in their entirety. For the tests provided to you, there is not a lot of output produced.

2.3 Error and Trap Handling

This section includes interrupt, fault, and SVC handling.

As you will see, this can be a lengthy amount of output. You should hand in enough output to demonstrate the proper handling of these errors and traps.

Consider using a similar scheme as the scheduler to show some error and trap handling, then disable it after some threshold has been exceeded. Whatever you set as a threshold, be sure it is high enough to show several instances of all the actions that might occur; in general if you set the threshold so all of test1a is displayed, you'll be OK.

3. An Example Of scheduler_printer Output

Here is an example of the output from scheduler_printer.

** Last time Process 0 'Dispatch' will be logged. **

** Last time Process 1 'Dispatch' will be logged. **

** Last time Process 2 'Dispatch' will be logged. **

** Last time Process 3 'Dispatch' will be logged. **

** Last time Process 4 'Dispatch' will be logged. **

** Last time Process 5 'Dispatch' will be logged. **

** Last time Process 6 'Dispatch' will be logged. **

** Last time Process 7 'Dispatch' will be logged. **

** Last time Process 8 'Dispatch' will be logged. **