Kernel Development Learning Pipeline

F1 - Contributing to Open Source Software 🤝

You will receive a specification and tests created per F0 by 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.

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 f1 folder will contain a directory with your name.
  • 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 your cover letter.
• Submit your patches to final1@kdlp.underground.software
  • Your initial submission is due by 11:59 PM the day before you present.
  • There will be no peer review.
  • Your final submission is due by 11:59 PM on the last day of presentations.

Procedure:

1. Locate and examine your assigned spec, tests, and makefile.
   • The f1 directory within the assignments repository contains named subdirectories for each student.
   • 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. This is especially important in the kernel.
   • 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 driver added by the previous patch must pass these tests without further modification.
   • Your next patch adds these tests to the existing file.

Submission Guidelines