diff --git a/Task08/task08.txt b/Task08/task08.txt
new file mode 100644
index 0000000..e581b5e
--- /dev/null
+++ b/Task08/task08.txt
@@ -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.