Kernel Development Learning Pipeline

E2 - Your first kernel module 🍿

You will specify, implement, and test a simple kernel module that creates a kdlp entry in the Linux kernel’s /proc filesystem with a basic read only interface that returns a unchanging message that includes the student’s name.

Outcomes:

• Get familiar with the internals of Linux’s /proc filesystem.
• Learn how to specify the behavior of a kernel module (/ software in general) with a guided example.
• Get familiar with software testing, how to write good tests, and how to develop code using tests as a guide.
• Write your first kernel module!

What to submit:

• A patch which adds a directory named firstname_listname to the E2 folder of the class repo with a filled out copy of the specification.txt file.
• A patch which adds your testing program and makefile.
• A patch which adds your kernel module and modifies the makefile to add support for compiling it.
• Don’t forget your cover letter (as always).

Procedure:

1. Create your named folder in the e2 directory, change directory into it, and copy the specification template into your folder (cp ../specification.txt .).
2. Edit your copy of specification.txt and fill in the blanks to fully specify the expected behavior of your module.
3. At this point you can git add the specification file and make your first commit.
4. Write a testing program and makefile that exercises all the functionality your driver will have according to the specification by performing operations on the file that it will create in /proc.
   • Be sure to write tests for all the behavior (existence of the file, file permissions, behavior of reading, writing, seeking, etc.).
   • Make sure to also test error conditions to make sure strange user input to your driver won’t crash the system, e.g. a null or invalid pointer.
   • You should have at least 10 distinct tests that the driver can pass or fail.
     • When run, the program should provide information about which tests succeeded or failed.
     • If a test failed, include in the program output how the behavior differed from what was expected.
   • At this point, you have nothing to test. In order to validate your testing program, temporarily change the hard-coded path of the file it opens.
     • Instead of opening a file in /proc, you can have it open a regular file whose contents/owner/permissions you can change manually to see which tests pass or fail.
     • Don’t forget to change this back before committing your code (or write your program / makefile in such a way that what file is used can be overridden from the default in /proc for testing).
5. At this point you can git add your makefile and testing program and make your second commit.
6. Implement the driver.
   • Update your makefile so it can build/clean, load/unload, and test your kernel driver.
   • See the example kernel module from the slides for information about how to create a basic module and build it.
   • The kernel code in fs/proc/cmdline.c and kernel/configs.c contain examples that create simple /proc entries that providing access read-only data.
   • Use the newer, better proc_create_single API from the /proc/cmdline code.
   • However, reference the code for /proc/config.gz for information on how to remove a /proc entry.
   • Hint: You can do this with three functions: init, exit, and one that generates the data.
   • Don’t overcomplicate things.
7. Submit your patches to exercise2@kdlp.underground.software by the due date.

Submission Guidelines