|author||Bryan Brattlof <firstname.lastname@example.org>||2020-07-15 17:10:06 -0400|
|committer||Bryan Brattlof <email@example.com>||2020-07-15 17:10:06 -0400|
task 18: add task readme
2 files changed, 70 insertions, 0 deletions
@@ -46,3 +46,5 @@ Here are the links to each task's readme:
16. Submit a Real Patch: `task <https://git.bryanbrattlof.com/eudyptula-challenge/tree/tasks/16/readme>`__
17. Using Kernel Treads: `task <https://git.bryanbrattlof.com/eudyptula-challenge/tree/tasks/17/readme>`__
+18. Handling Delayed Work: `task <https://git.bryanbrattlof.com/eudyptula-challenge/tree/tasks/18/readme>`__
diff --git a/tasks/18/readme b/tasks/18/readme
new file mode 100644
@@ -0,0 +1,68 @@
+Nice job with the kernel thread. It really doesn't take much code at
+all to create a new thread. So now let us get some data into the module
+to give the thread something to do.
+Base all of this work on your task 17 codebase.
+Go back and dig up task 12's source code, the one with the list
+handling. Copy the structure into this module, and the
+identity_create(), identity_find(), and identity_destroy() functions
+into this module as well.
+Write a new function, identity_get(), that looks like:
+ struct identity identity_get(void);
+and returns the next "identity" structure that is on the list, and
+removes it from the list. If nothing is on the list, return NULL.
+Then, hook up the misc char device "write" function to do the following:
+ - If a write is larger than 19 characters, truncate it at 19.
+ - Take the write data and pass it to identity_create() as the string,
+ and use an incrementing counter as the "id" value.
+ - Wake up the "wee_wait" queue.
+In the kernel thread function:
+ - If the "wee_wait" queue wakes us up, get the next identity in the
+ system with a call to identity_get().
+ - Sleep (in an interruptable state, don't go increasing the system
+ load in a bad way) for 5 seconds.
+ - Write out the identity name, and id to the debug kernel log and then
+ free the memory.
+When the module exits, clean up the whole list by using the functions
+given, no fair mucking around with the list variables directly.
+Yes, it's a bit clunky, but it shows the basics of taking work from
+userspace, and then quickly returning to the user, and then going off
+and doing something else with the data and cleaning everything up. It's
+a common pattern for a kernel, as it's really all that a kernel ends up
+doing most of the time (get a disk block, write a disk block, handle a
+mouse event, etc.)
+Load and unload the module and "prove" that it works properly by writing
+and looking at the debug log, and that everything cleans up properly
+when the module is unloaded.
+Send in the proof and the .c file for the module.
+A good test script would be the following:
+ echo "Alice" > /dev/eudyptula
+ echo "Bob" > /dev/eudyptula
+ sleep 15
+ echo "Dave" > /dev/eudyptula
+ echo "Gena" > /dev/eudyptula
+ rmmod task18
+Removing the module while there is pending work is always a good stress