8f05fb6f36d07dd6337397f1fda45313c0eae883 — Bryan Brattlof 3 years ago 05fd4a8
task 9: add task readme
2 files changed, 29 insertions(+), 0 deletions(-)

M readme.rst
A tasks/09/readme
M readme.rst => readme.rst +2 -0
@@ 28,3 28,5 @@ Here are the links to each task's readme:
7. Building Linux-Next: `task <https://git.bryanbrattlof.com/eudyptula-challenge/tree/tasks/07/readme>`__

8. Working with debugfs: `task <https://git.bryanbrattlof.com/eudyptula-challenge/tree/tasks/08/readme>`__

9. Working with sysfs: `task <https://git.bryanbrattlof.com/eudyptula-challenge/tree/tasks/09/readme>`__

A tasks/09/readme => tasks/09/readme +27 -0
@@ 0,0 1,27 @@
Task 09

Nice job with debugfs, that is a handy thing to remember when wanting to
print out some debugging information.  Never use /proc/ that is only for
processes, use debugfs instead.

Along with debugfs, sysfs is a common place to put information that
needs to move from the user to the kernel.  So let us focus on sysfs for
this task.

The task this time:

  - Take the code you wrote in task 08, and move it to sysfs.  Put the
    "eudyptula" directory under the /sys/kernel/ location in sysfs.

  - Provide some "proof" this works.

That's it!  Simple, right?  No, you are right, it's more complex, sysfs
is complicated.  I'd recommend reading Documentation/kobject.txt as a
primer on how to use kobjects and sysfs.

Feel free to ask for hints and help with this one if you have questions
by sending in code to review if you get stuck, many people have dropped
out in the challenge at this point in time, so don't feel bad about
asking, we don't want to see you go away just because sysfs is so damn