63 lines
2.9 KiB
Text
63 lines
2.9 KiB
Text
This is Task 08 of the Eudyptula Challenge
|
|
------------------------------------------
|
|
|
|
We will come back to the linux-next kernel in a later exercise, so don't
|
|
go and delete that directory, you'll want it around. But enough of
|
|
building kernels, let's write more code!
|
|
|
|
This task is much like the 06 task with the misc device, but this time
|
|
we are going to focus on another user/kernel interface, debugfs. It is
|
|
rumored that the creator of debugfs said that there is only one rule for
|
|
debugfs use": "There are no rules when using debugfs." So let's take
|
|
them up on that offer and see how to use it.
|
|
|
|
debugfs should be mounted by your distro in /sys/kernel/debug/. If it
|
|
isn't, then you can mount it with the line:
|
|
mount -t debugfs none /sys/kernel/debug/
|
|
|
|
Make sure it is enabled in your kernel, with the CONFIG_DEBUG_FS option,
|
|
you will need it for this task.
|
|
|
|
The tasks, in specifics are:
|
|
|
|
- Take the kernel module you wrote for task 01, and modify it to
|
|
create a debugfs subdirectory called "eudyptula". In that
|
|
directory, create the virtual file called "id".
|
|
- This "id" file, operates just like it did for example 06, and uses
|
|
the same logic there, the file is to be readable and writable by any
|
|
user.
|
|
- Submit this task as the first email.
|
|
- Base your work on this submission, and create a new debugfs file
|
|
called "jiffies".
|
|
- This "jiffies" file is to be read-only by any user, and when read,
|
|
should return the current value of the jiffies kernel timer.
|
|
- Submit this result as a patch against the first email.
|
|
- Base your work again on that submission, and create a final debugfs
|
|
file called "foo".
|
|
- The file "foo" needs to be writable only by root, but readable by
|
|
anyone. When writing to it, the value must be stored, up to one
|
|
page of data. When read, which can be done by any user, the value
|
|
that is stored in it must be returned. Properly handle the fact
|
|
that someone could be reading from the file while someone else is
|
|
writing to it (oh, a locking hint!)
|
|
- Submit this result as a patch against the second email.
|
|
- When the module is unloaded, all of the debugfs files are cleaned
|
|
up, and any memory allocated is freed, for all submissions.
|
|
- Provide some "proof" this all works in the first email.
|
|
|
|
Again, you are using your id in the code, so you know what it is by now,
|
|
no need to repeat it again.
|
|
|
|
So, for this task, I expect to see 3 emails, all "linked" somehow, in my
|
|
mailbox. They should look something like this:
|
|
|
|
[redacted] Task 08 results
|
|
├─>[redacted] [PATCH 01/02] Task 08: add jiffies file
|
|
└─>[redacted] [PATCH 02/02] Task 08: add foo file
|
|
|
|
Or, even better:
|
|
[redacted] Task 08 results
|
|
└─>[redacted] [PATCH 01/02] Task 08: add jiffies file
|
|
└─>[redacted] [PATCH 02/02] Task 08: add foo file
|
|
|
|
Hint, look at using 'git send-email' as a way to send these files out.
|