From ad35c6a32df33c1cdd1e875c9d900249ee8e89e9 Mon Sep 17 00:00:00 2001 From: Guru Das Srinagesh Date: Tue, 16 May 2017 01:05:46 -0700 Subject: [PATCH] Add Task 18 description --- Task18/task18.txt | 59 +++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 59 insertions(+) create mode 100644 Task18/task18.txt diff --git a/Task18/task18.txt b/Task18/task18.txt new file mode 100644 index 0000000..d44f32b --- /dev/null +++ b/Task18/task18.txt @@ -0,0 +1,59 @@ +This is Task 18 of the Eudyptula Challenge +------------------------------------------ + +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 +test.