Add Task 08 description
This commit is contained in:
parent
835c6736a3
commit
97de86ceb7
|
@ -0,0 +1,63 @@
|
|||
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.
|
Loading…
Reference in New Issue