CS 452/652 Winter 2024 - Kernel (Part 3)

(Version: 1)

Due Date: Thu, Feb 15, 2024, 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
  1. an implementation of the AwaitEvent() system call,
  2. an implementation of an idle task,
  3. implementations of a clock server and a clock notifier, and
  4. implementations of Time(), Delay(), and DelayUntil() as wrappers for Send() to the clock server.
  5. an implementation of clock server client tasks, for testing.
Tasks that want to obtain service from the clock server must do so by obtaining its tid from the name server.

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 creats the clock server and 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 is a helper task that is created by the clock server. The notifier waits on events from a timer, and sends 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 to receive the parameter requests from the four client tasks. It 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
31020
4239
5336
6713

Idle Task

During the time that all client tasks are delayed, an idle task should run. The idle task should report the fraction of execution time that it (the idle task) uses. This should be displayed on the console. We will expect you to maintain this performance indicator throughout the remainder of the term. You will find it a useful diagnostic of performance problems. The idle task should put the CPU into a low-power state.

Submission

Your readable and documented source code should be in your repository at https://git.uwaterloo.ca. The repository must be set to 'Private' with instructor and TAs added as 'Reporter'. Your repo should include a README-K3 file, which describes how to make and operate your program. Each group should be working from a single repository.

Each group should submit a single PDF file into the K3 dropbox for this course in Learn. The PDF should include the following information:

  1. The names, userids, and student IDs of your group members.
  2. The name of your group's code repository on git.uwaterloo.ca and the SHA of the commit that we should be using for this assignment. The commit must be dated before the assignment deadline.
  3. A description of the structure of your kernel so far. Aside from testing, we will judge your program primarily on the basis of this description. Describe which algorithms and data structures you use and why you chose them. Describe your choices for critical system parameters and limitations, such as stack size, maximum number of tasks, etc.
  4. If appplicable, a description of unimplemented aspects of the assignment. Also, if you know of bugs in your implementation describe them explicitly.
In addition, the following material should be present in your git repository, in addition to your code:
  1. The README-K3 file indicating how to build and run your game test. We should be able to build and run your code in the linux.student.cs environment without having to edit any files. We'll be running your test and use the description in your PDF file to interpret the results.

We may perform code reviews with students, in which case a TA/instructor and will contact you to set up a meeting.