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 which includes the student's name.
Get familiar with the internals of Linux's
/proc
filesystem
Learn how to specify the behavior of a kernel module 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!
A first patch adds a directory username/E2
to the assignment repo with a filled out copy of the specification.txt
file.
A second patch which adds your testing program and makefile to username/E2
A patch which adds your kernel module source to username/E2
and modifies the makefile to add support for compiling it
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 exercise2@COURSE_DOMAIN
Create your username/E2
directory
E2.txt
from the repository root as username/E2/specification.txt
Edit your copy of specification.txt
and fill in the blanks
to fully specify the expected behavior of your module.
At this point you can git add
the specification file and make your first commit
Write a testing program and makefile
that exercises all the functionality your module 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 module won't crash the system, e.g. a null or invalid pointer
You should have at least 10 distinct tests that the module 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)
At this point you can git add
your makefile and testing program
and make your second commit
Implement the module
Update your makefile so it can build/clean, load/unload, and test your kernel module
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
msg = (silence)
whoami = None
singularity v0.5 https://github.com/underground-software/singularity