Objectives and Logistics

Lab Objective and Summary

This lab has you implement device drivers in a production-ready operating system (OS): the Linux kernel, written in C. Linux is one of the, if not the most widespread OS. It dominates many markets including servers, cloud infrastructure, HPC, and mobile (Android), running on billions of devices, despite its lower desktop/laptop share.

A hardware device is an I/O component (disk, GPU, keyboard, screen, network card, speaker, etc.). A device driver is OS code that directly manipulates a device and exposes a convenient interface for user-space applications to use it via system calls, the mechanism applications use to invoke the OS:

You will follow a process similar to that used by industry contributors to the Linux kernel: given a datasheet describing a device’s OS-facing interface, you write the driver that uses it, calling on Linux kernel APIs (device/driver registration, memory mapping and allocation, I/O memory access, interrupt management, user-space communication, etc.). User-space test applications and test suites validate each device’s operation.

The kernel you modify will run inside a virtual machine emulating the target devices.

Lab Structure

You will write a Linux driver for each of three components, of increasing complexity:

1. A synchronous random number generator (RNG). Synchronous means that a request to generate a random number is answered immediately.
2. An asynchronous RNG, in which a request is answered after a delay.
3. A data compressor.

Guidance decreases across the three: instructions for implementing the synchronous RNG driver are very detailed, the asynchronous RNG less so, and the compressor is implemented with no help beyond the datasheet.

Use of AI and Plagiarism

Use of AI

Generative AI use is mostly authorised for that exercise, but should be used responsibly, i.e., in a way that encourages rather than prevents learning:

1. AI use is not recommended for the basic version of the synchronous RNG driver: the relevant part of the brief is guided enough to be completed by simply following instructions, and using AI here will likely prevent you from learning basic concepts needed later.
2. Authorised for the enhanced synchronous RNG driver, the asynchronous RNG driver, and the compressor driver, as the brief provides much less guidance for these.

Whenever you use AI, study the code produced until you understand it well: the COMP26020 exam assesses your knowledge of technical aspects of the code produced as part of this exercise, AI-generated or not.

AI may generate code using kernel/C features you’re unfamiliar with and understanding it is part of the exercise. Ask the AI to explain anything you struggle with. If you doubt its output, check alternative sources:

• Linux kernel: the code itself is the best documentation — browse and search definitions/references via Linux Cross Reference.
• C language: covered in the lectures; a more comprehensive reference is cppreference.
• Come to the lab support sessions scheduled on campus, and use the discussion board on Canvas.

Plagiarism

Do not copy code from other students. All submissions are checked electronically for plagiarism, with suspicious cases reported to the administration.

Deadline and Submission Format

The deadline is indicated on the course unit’s page on Canvas; standard University late penalties apply.

The deliverable is a single patch file for the Linux kernel containing your driver code (instructions at the end of this brief), submitted via the CS Department’s GitLab on a repository named 26020-lab1-s-drivers_<your username> associated with your username. That repository will be created automatically and you do not have to create it yourself or fork another repository. Push the patc hfile to the default (main) branch of the repository and create a tag named lab1-submission to mark it ready.

Submission Checklist

⚠️ ⚠️ ⚠️ Before submitting, please complete this checklist: ⚠️ ⚠️ ⚠️

• I have pushed to the correct repository and tagged it properly.
• Even if I have not fully completed the exercise, my patch applies without errors or warnings to an unmodified clone of the Linux v6.6 sources.
• The patch contains only the drivers’ code changes, no binary or build files.

Failure to follow these instructions will likely result in a mark of 0 for this exercise.

Marking Scheme

It is highly recommended to complete every part of that exercise in order.

Intended Learning Objectives

Beyond low-level systems software development, this assignment exercises core C and imperative programming skills:

• Structure programs into functions, including function pointers as callbacks, for modular, reusable control flow.
• Express program logic with core imperative constructs for polling, command dispatch, and error handling.
• Use custom data structures, fixed-width integer types, and bitwise operations for hardware register state and command encodings.
• Manipulate raw memory through pointers, using accessor functions over direct dereference when correctness depends on execution order and side effects.
• Use the C preprocessor and header files for shared constants and interfaces, separating declarations from implementation.

Favicon by icons8.com.