CS 452/652 Fall 2022 - Kernel (Part 3)
(Version: 1)
Due Date: Thu, Oct 20, 2022, 9:00am
Introduction
The third part of your kernel adds interrupts generated by a timer. You use this capability to create a clock server. To do so you must have working
- an implementation of AwaitEvent(),
- an implementation of an idle task, or equivalent,
- implementations of a clock server and a clock notifier, and
- implementations of Time(), Delay(), and DelayUntil() as wrappers for Send() to the clock server.
Tasks that want to obtain service from the clock server must do so by obtaining its tid from the name server.
Comment
It is possible to use a single kernel entry point for hardware and software interrupts. The set of things needed to handle software interrupts is a subset of the set needed for hardware interrupts so a correct implementation of hardware interrupts works fine for software ones. This shrinks the code size at the cost of executing some extra instructions. However, multiple entry points, using assembler macros to reduce the size of the source code, is also fine.
Description
Kernel
To accomplish this part of the kernel you must have the following kernel primitive
operating:
int AwaitEvent(int eventType)
See the kernel description for the details of how this primitive should operate. In addition you must program a first user task, which
- creates the name server,
- creates the clock server, and
- creates the clock server's clients.
The Clock Server and Notifier
The clock server should be implemented as described in the kernel documentation. The clock notifier should wait on events from a timer, and send notifications that the timer ticked to the clock server.
Client Tasks
A single type of client task tests your kernel and clock server. It is created by the first user task, and immediately sends to its parent, the first user task, requesting a delay interval, t in ticks, and a number, n, of delays. It then uses WhoIs() to discover the tid of the clock server.
It then delays n times, each time for the delay interval, t. After each delay it prints its tid, its delay interval, and the number of delays currently completed on the terminal connected to the ARM box.
FirstUserTask
The first user task creates the clock server, and four client tasks with different priorities. It then executes Receive() four times, and replies to each client task in turn. The following table shows the parameters to be given to the clients.
| Priority (smaller is higher) | Delay Interval (in ticks) | Number of Delays
|
| 3 | 10 | 20
|
| 4 | 23 | 9
|
| 5 | 33 | 6
|
| 6 | 71 | 3
|
Idle Task
During the time that all client tasks are delayed, an idle task should run. You can use the idle task to measure and report on operating characteristics of your system. One operating characteristic you must produce for this assignment is the fraction of execution time used by the idle task. This must be shown on the terminal display. We will expect you to maintain this performance indicator throughout the remainder of the term. You will find it an invaluable diagnostic of performance problems. Ideally, the idle task should put the CPU into a low-power halt state.
Hand In
Hand in the following, nicely formatted and printed.
- A pointer to your code repository, readable by the TAs and instructor, containing the source code of your assignment, instructions how to make the executable, and documentation (see below). The code and documentation must remain unmodified after submission until the assignments have been marked. Email the commit SHA to the instructor before the deadline.
- A description of how to access, make, and operate your program in a README file, including the full pathname of your executable file, which we might download for testing.
- The names of your group members in the same README file.
- A description of the structure of your kernel so far, highlighting the changes for this assignment. We will judge your kernel primarily on the basis of this description. Describe which algorithms and data structures you used and why you chose them. Describe your choices for critical system parameters and limitations, such as stack size, maximum number of tasks, etc.
- Output produced by your client tasks and an explanation of why it occurs in the order it does.
- Note that we intend to perform code reviews with students. A TA/instructor and might contact you to set up a (virtual) meeting.