Kernel Development Learning Pipeline

F1 - Contributing to Open Source Software 🤝

You will receive a specification and tests created per F0 by yourself or one of your colleagues.

You must implement the character device from spec as a Linux kernel module.

Your colleague's tests will pass when run against your implementation.

Unlike all previous assignments, there will be no peer review and only one submission.

Outcomes:

• Put your knowledge of character devices into practice

• Demonstrate your reading comprehension of technical topics

• Simulate real software engineering teamwork and communication

• Discern between your own errors and those of others while working with imperfect information

What to submit:

• The submissions repository will contain a username/F1 directory

  • Within you will find your given spec, tests, and a makefile to build them

• If there are any bugs in the tests, your first patch fixes them

• Your next patch (the first if you determine the tests to be bug-free) adds your module

  • The module code and its makefile will be created in a folder named module within your named directory

• Your final patch adds additional tests to the provided program

• Don’t forget a cover letter

• All email code patches are expected to pass checkpatch.pl as described in the policies and procedures

• Submit your patches to final1@COURSE_DOMAIN

  • Your submission must be made before you submit your final presentation

  • There will be no peer review

  • Your final presentation must use the exact same version of the code as your submission

Procedure:

1. Locate and examine your assigned spec, tests, and makefile

   • The provided makefile should build the tests as the default target

   • However, initially there is nothing to test

2. Carefully review the spec and examine each of the test cases

   • It will be helpful to begin by associating each test case with the corresponding part of the spec

   • If you find any issues, inconsistencies, or ambiguities in the spec or tests, then:

     • For simple problems, fix the issue yourself as you see fit. You may take some creative liberty but do your best to maintain the intent of the original author.

     • For more puzzling concerns, communicate with the original author and/or post in the #questions channel on KDLP Matrix

   • Think about whether the given test file tests all cases

     • This will give you a head start later when you are writing additional tests

   • If you modify the spec, you may need to adjust some tests to reflect these updates

   • Your first patch will consist of any adjustments you make to the spec or tests

   • If you do not need to make any changes, then your series won't include this patch

3. Using the now thoroughly reviewed spec, implement the character device it describes

   • First, create a subdirectory within your named folder called module

   • Use the kernel's miscdevice API to register and de-register your character device

     • This is standard practice for simple kernel drivers implemented as character devices.

   • Implement one syscall at a time and focus only on the tests pertaining to that syscall

   • Assume an arbitrary number of processes will be accessing your character device at the same time

   • Assume that any of the threads in these processes may be interrupted after any line of code for an arbitrary amount of time

   • Code designed to run in these conditions must be reentrant.

   • To properly implement this concurrent behavior, you must enforce mutual exclusion around any access to shared data

   • As always, no memory leaks, no use-after-free, no buffer overflows

   • Once all the tests pass, make your next commit

4. Create 5 new tests

   • Try to add new tests for untested edge cases, areas of the spec that you may have changed, or more complicated integrations of multiple syscalls in a row

   • Your module added by the previous patch must pass these tests without further modification

   • Your next patch adds these tests to the existing file

Policies & Procedures