Advertisement
Not a member of Pastebin yet?
Sign Up,
it unlocks many cool features!
- This is Task 01 of the Eudyptula Challenge
- ------------------------------------------
- Write a Linux kernel module, and stand-alone Makefile, that when loaded
- prints to the kernel debug log level, "Hello World!" Be sure to make
- the module be able to be unloaded as well.
- The Makefile should build the kernel module against the source for the
- currently running kernel, or, use an environment variable to specify
- what kernel tree to build it against.
- Please show proof of this module being built, and running, in your
- kernel. What this proof is is up to you, I'm sure you can come up with
- something. Also be sure to send the kernel module you wrote, along with
- the Makefile you created to build the module.
- Remember to use your ID assigned to you in the Subject: line when
- responding to this task, so that I can figure out who to attribute it
- to. You can just respond to the task with the answers and all should be
- fine.
- If you forgot, your id is "7c1caf2f50d1". But of course you have not
- forgotten that yet, you are better than that.
- This is Task 02 of the Eudyptula Challenge
- ------------------------------------------
- Now that you have written your first kernel module, it's time to take
- off the training wheels and move on to building a custom kernel. No
- more distro kernels for you, for this task you must run your own kernel.
- And use git! Exciting isn't it! No, oh, ok...
- The tasks for this round is:
- - download Linus's latest git tree from git.kernel.org (you have to
- figure out which one is his, it's not that hard, just remember what
- his last name is and you should be fine.)
- - build it, install it, and boot it. You can use whatever kernel
- configuration options you wish to use, but you must enable
- CONFIG_LOCALVERSION_AUTO=y.
- - show proof of booting this kernel. Bonus points for you if you do
- it on a "real" machine, and not a virtual machine (virtual machines
- are acceptable, but come on, real kernel developers don't mess
- around with virtual machines, they are too slow. Oh yeah, we aren't
- real kernel developers just yet. Well, I'm not anyway, I'm just a
- script...) Again, proof of running this kernel is up to you, I'm
- sure you can do well.
- Hint, you should look into the 'make localmodconfig' option, and base
- your kernel configuration on a working distro kernel configuration.
- Don't sit there and answer all 1625 different kernel configuration
- options by hand, even I, a foolish script, know better than to do that!
- After doing this, don't throw away that kernel and git tree and
- configuration file. You'll be using it for later tasks, a working
- kernel configuration file is a precious thing, all kernel developers
- have one they have grown and tended to over the years. This is the
- start of a long journey with yours, don't discard it like was a broken
- umbrella, it deserves better than that.
- Remember to use your ID assigned to you in the Subject: line when
- responding to this task, so that I can figure out who to attribute it
- to.
- If you forgot, your id is "7c1caf2f50d1". But why do I repeat myself?
- Of course you know your id, you made it through the first task just fine
- with it.
- This is Task 03 of the Eudyptula Challenge
- ------------------------------------------
- Now that you have your custom kernel up and running, it's time to modify
- it!
- The tasks for this round is:
- - take the kernel git tree from Task 02 and modify the Makefile to
- and modify the EXTRAVERSION field. Do this in a way that the
- running kernel (after modifying the Makefile, rebuilding, and
- rebooting) has the characters "-eudyptula" in the version string.
- - show proof of booting this kernel. Extra cookies for you by
- providing creative examples, especially if done in intrepretive
- dance at your local pub.
- - Send a patch that shows the Makefile modified. Do this in a manner
- that would be acceptable for merging in the kernel source tree.
- (Hint, read the file Documentation/SubmittingPatches and follow the
- steps there.)
- Remember to use your ID assigned to you in the Subject: line when
- responding to this task, so that I can figure out who to attribute it
- to.
- If you forgot, your id is "7c1caf2f50d1". Surely I don't need to keep
- saying this right? I know, _you_ wouldn't forget, but someone else, of
- course they would, so I'll just leave it here for those "others".
- This is Task 04 of the Eudyptula Challenge
- ------------------------------------------
- Wonderful job in making it this far, I hope you have been having fun.
- Oh, you're getting bored, just booting and installing kernels? Well,
- time for some pedantic things to make you feel that those kernel builds
- are actually fun!
- Part of the job of being a kernel developer is recognizing the proper
- Linux kernel coding style. The full description of this coding style
- can be found in the kernel itself, in the Documentation/CodingStyle
- file. I'd recommend going and reading that right now, it's pretty
- simple stuff, and something that you are going to need to know and
- understand. There is also a tool in the kernel source tree in the
- scripts/ directory called checkpatch.pl that can be used to test for
- adhering to the coding style rules, as kernel programmers are lazy and
- prefer to let scripts do their work for them...
- And why a coding standard at all? That's because of your brain (yes,
- yours, not mine, remember, I'm just some dumb shell scripts). Once your
- brain learns the patterns, the information contained really starts to
- sink in better. So it's important that everyone follow the same
- standard so that the patterns become consistent. In other words, you
- want to make it really easy for other people to find the bugs in your
- code, and not be confused and distracted by the fact that you happen to
- prefer 5 spaces instead of tabs for indentation. Of course you would
- never prefer such a thing, I'd never accuse you of that, it was just an
- example, please forgive my impertinence!
- Anyway, the tasks for this round all deal with the Linux kernel coding
- style. Attached to this message are two kernel modules that do not
- follow the proper Linux kernel coding style rules. Please fix both of
- them up, and send it back to me in such a way that does follow the
- rules.
- What, you recognize one of these modules? Imagine that, perhaps I was
- right to accuse you of the using a "wrong" coding style :)
- Yes, the logic in the second module is crazy, and probably wrong, but
- don't focus on that, just look at the patterns here, and fix up the
- coding style, do not remove lines of code.
- As always, please remember to use your ID assigned to you in the
- Subject: line when responding to this task, so that I can figure out who
- to attribute it to. And if you forgot (which of course you have not,
- we've been through all of this before), your id is "7c1caf2f50d1".
- This is Task 05 of the Eudyptula Challenge
- ------------------------------------------
- Yeah, you survived the coding style mess! Now, on to some "real"
- things, as I know you are getting bored by these so far.
- So, simple task this time around:
- - take the kernel module you wrote for task 01, and modify it so that
- when a USB keyboard is plugged in, the module will be automatically
- loaded by the correct userspace hotplug tools (which are implemented
- by depmod / kmod / udev / mdev / systemd, depending on what distro
- you are using.)
- Yes, so simple, and yet, it's a bit tricky. As a hint, go read chapter
- 14 of the book, "Linux Device Drivers, 3rd edition." Don't worry, it's
- free, and online, no need to go buy anything.
- As always, please remember to use your ID assigned to you, yadda yadda
- yadda... It's "7c1caf2f50d1" of course.
- This is Task 06 of the Eudyptula Challenge
- ------------------------------------------
- Nice job with the module loading macros, those are tricky, but a very
- valuable skill to know about, especially when running across them in
- real kernel code.
- Speaking of real kernel code, let's write some!
- The task this time is this:
- - Take the kernel module you wrote for task 01, and modify it to be a
- misc char device driver. The misc interface is a very simple way to
- be able to create a character device, without having to worry about
- all of the sysfs and character device registration mess. And what a
- mess it is, so stick to the simple interfaces wherever possible.
- - The misc device should be created with a dynamic minor number, no
- need running off and trying to reserve a real minor number for your
- test module, that would be crazy.
- - The misc device should implement the read and write functions.
- - The misc device node should show up in /dev/eudyptula.
- - When the character device node is read from, your assigned id is
- returned to the caller.
- - When the character device node is written to, the data sent to the
- kernel needs to be checked. If it matches your assigned id, then
- return a correct write return value. If the value does not match
- your assigned id, return the "invalid value" error value.
- - The misc device should be registered when your module is loaded, and
- unregistered when it is unloaded.
- - Provide some "proof" this all works properly.
- As you will be putting your id into the kernel module, of course you
- haven't forgotten it, but just to be safe, it's "7c1caf2f50d1".
- This is Task 07 of the Eudyptula Challenge
- ------------------------------------------
- Great work with that misc device driver. Isn't that a nice and simple
- way to write a character driver?
- Just when you think this challenge is all about writing kernel code,
- this task is a throwback to your second one. Yes, that's right,
- building kernels. Turns out that's what most developers end up doing,
- tons and tons of rebuilds, not writing new code. Sad, but it is a good
- skill to know.
- The tasks this round are:
- - Download the linux-next kernel for today. Or tomorrow, just use
- the latest one. It changes every day so there is no specific one
- you need to pick. Build it. Boot it. Provide proof that you built
- and booted it.
- What is the linux-next kernel? Ah, that's part of the challenge.
- For a hint, you should read the excellent documentation about how the
- Linux kernel is developed in Documentation/development-process/ in the
- kernel source itself. It's a great read, and should tell you all you
- never wanted to know about what Linux kernel developers do and how they
- do it.
- As always, please respond to this challenge with your id. I know you
- know what it is. I'll not even include it this time, I trust you.
- Don't make me feel that is a mistake.
- 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 task, in specifics is:
- - Take the kernel module you wrote for task 01, and modify it to be
- create a debugfs subdirectory called "eudyptula". In that
- directory, create 3 virtual files called "id", "jiffies", and "foo".
- - The file "id" operates just like it did for example 06, use the same
- logic there, the file must be readable and writable by any user.
- - The file "jiffies" is to be read only by any user, and when read,
- should return the current value of the jiffies kernel timer.
- - 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
- must be returned that is stored it it. Properly handle the fact
- that someone could be reading from the file while someone else is
- writing to it (oh, a locking hint!)
- - When the module is unloaded, all of the debugfs files are cleaned
- up, and any memory allocated is freed.
- - Provide some "proof" this all works.
- Again, you are using your id in the code, so you know what it is by now,
- no need to repeat it again.
- This is Task 09 of the Eudyptula Challenge
- ------------------------------------------
- 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
- complicated.
- This is Task 10 of the Eudyptula Challenge
- ------------------------------------------
- Yeah, you conquered the sysfs monster, great job!
- Now you know to never want to mess with a kobject again, right? Trust
- me, there are easier ways to create sysfs files, and we will get into
- that for a future task, but for now, let's make it a bit more simple
- after all of that coding.
- For this task, go back to the linux-next tree you used for task 07.
- Update it, and then do the following:
- - Create a patch that fixes one coding style problem in any of the
- files in drivers/staging/
- - Make sure the patch is correct by running it through
- scripts/checkpatch.pl
- - Submit the code to the maintainer of the driver/subsystem, finding
- the proper name and mailing lists to send it to by running the tool,
- scripts/get_maintainer.pl on your patch.
- - Send a web link back to me of your patch on the public mailing list
- archive (don't cc: me on the patch, that will only confuse me and
- everyone in the kernel development community.)
- - If you want to mention the Eudyptula Challenge as the reason for
- writing the patch, feel free to do so in the body of the patch, but
- it's not necessary at all.
- Hopefully this patch will be accepted into the kernel tree, and all of a
- sudden, you are an "official" kernel developer!
- Don't worry, there's plenty more tasks coming, but a little breather
- every now and again for something simple is always nice to have.
- This is Task 11 of the Eudyptula Challenge
- ------------------------------------------
- You made a successful patch to the kernel source tree, that's a great
- step!
- But, let's not rest, time to get back to code.
- Remember that mess of kobject and sysfs code back in task 09? Let's
- move one level up the tree and start to mess with devices and not raw
- kobjects.
- For this task:
- - Write a patch against any driver that you are currently using on
- your machine. So first you have to figure out which drivers you are
- using, and where the source code in the kernel tree is for that
- driver.
- - In that driver, add a sysfs file to show up in the /sys/devices/
- tree for the device that is called "id". As you might expect, this
- file follows the same rules as task 09 as for what you can read and
- write to it.
- - The file is to show up only for devices that are controlled by a
- single driver, not for all devices of a single type (like all USB
- devices. But all USB maibox LEDs would be acceptable, if you happen
- to have the device that that driver controls.)
- Submit both the patch, in proper kernel commit form, and "proof" of it
- working properly on your machine.
- And as always, please use your id in the subject line. If you happened
- to forget it, as it has been a while since I reminded you of it, it is
- "7c1caf2f50d1".
- This is Task 12 of the Eudyptula Challenge
- ------------------------------------------
- Nice job with the driver patch. That took some work in finding the
- proper place to modify, and demonstrates a great skill in tracking down
- issues when you can't get a specific piece of hardware working.
- Now let's step back from drivers (they are boring things), and focus on
- the kernel core. To do that, we need to go way back to the basics --
- stuff you would learn in your "intro to data structures" class, if you
- happened to take one.
- Yes, I'm talking about linked lists.
- The kernel has a unique way of creating and handling linked lists, that
- is quite different than the "textbook" way of doing so. But, it turns
- out to be faster, and simpler, than a "textbook" would describe, so
- that's a good thing.
- For this task, write a kernel module, based on your cleaned up one from
- task 04, that does the following:
- - You have a structure that has 3 fields:
- char name[20];
- int id;
- bool busy;
- name this structure "identity".
- - Your module has a static variable that points to a list of these
- "identity" structures.
- - Write a function that looks like:
- int identity_create(char *name, int id)
- that creates the structure "identity", copies in the 'name' and 'id'
- fields and sets 'busy' to false. Proper error checking for out of
- memory issues is required. Return 0 if everything went ok; an error
- value if something went wrong.
- - Write a function that looks like:
- struct identity *identity_find(int id);
- that takes a given id, iterates over the list of all ids, and
- returns the proper 'struct identity' associated with it. If the
- identity is not found, return NULL.
- - Write a function that looks like:
- void identity_destroy(int id);
- that given an id, finds the proper 'struct identity' and removes it
- from the system.
- - Your module_init() function will look much like the following:
- struct identity *temp;
- identity_create("Alice", 1);
- identity_create("Bob", 2);
- identity_create("Dave", 3);
- identity_create("Gena", 10);
- temp = identity_find(3);
- pr_debug("id 3 = %s\n", temp->name);
- temp = identity_find(42);
- if (temp == NULL)
- pr_debug("id 42 not found\n");
- identity_destroy(2);
- identity_destroy(1);
- identity_destroy(10);
- identity_destroy(42);
- identity_destroy(3);
- Bonus points for properly checking return values of the above
- functions.
- As always, please send the full module (following the proper kernel
- coding style rules), and "proof" of it working properly. And remember
- to use your id of "7c1caf2f50d1" in the Subject line properly.
- This is Task 13 of the Eudyptula Challenge
- ------------------------------------------
- Weren't those lists fun to play with? You should get used to them, they
- are used all over the kernel in lots of different places.
- Now that we are allocating a structure that we want to use a lot of, we
- might want to start caring about the speed of the allocation, and not
- have to worry about the creation of those objects from the "general"
- memory pools of the kernel.
- This task is to take the code written in task 12, and cause all memory
- allocated from the 'struct identity' to come from a private slab cache
- just for the fun of it.
- Instead of using kmalloc() and kfree() in the module, use
- kmem_cache_alloc() and kmem_cache_free() instead. Of course this means
- you will have to initialize your memory cache properly when the module
- starts up. Don't forget to do that. You are free to name your memory
- cache whatever you wish, but it should show up in the /proc/slabinfo
- file.
- Don't send the full module for this task, only a patch with the diff
- from task 12 showing the lines changed. This means you will have to
- keep a copy of your 12 task results somewhere to make sure you don't
- overwrite them.
- Also show the output of /proc/slabinfo with your module loaded.
- This is Task 14 of the Eudyptula Challenge
- ------------------------------------------
- Now that you have the basics of lists, and we glossed over the custom
- allocators (the first cut at that task was much harder, you got off
- easy), it's time to move on to something a bit more old-school: tasks.
- For this task:
- - Add a new field to the core kernel task structure called, wait for
- it, "id".
- - When the task is created, set the id to your id. Imaginative, I
- know. You try writing these tasks.
- - Add a new proc file for every task called, "id", located in the
- /proc/${PID}/ directory for that task.
- - When the proc file is read from, have it print out the value of
- your id, and then increment it by one, allowing different tasks to
- have different values for the "id" file over time as they are read
- from.
- - Provide some "proof" it all works properly.
- As you are touching files all over the kernel tree, a patch is the
- required result to be sent in here. Please specify which kernel version
- you make this patch against, to give my virtual machines a chance to
- figure out how to apply it.
- Also provide some kind of proof that you tested the patch.
- And, in case you happened to forget it, your id is "7c1caf2f50d1".
- This is Task 15 of the Eudyptula Challenge
- ------------------------------------------
- That process task turned out to not be all that complex, but digging
- through the core kernel was a tough task, nice work with that.
- Speaking of "core kernel" tasks, let's do another one. It's one of the
- most common undergraduate tasks there is: create a new syscall!
- Yeah, loads of fun, but it's good to know the basics of how to do this,
- and, how to call it from userspace.
- For this task:
- - Add a new syscall to the kernel called "sys_eudyptula", so this is
- all going to be changes to the kernel tree itself, no stand-alone
- module needed for this task (unless you want to do it that way
- without hacking around the syscall table, if so, bonus points for
- you...)
- - The syscall number needs to be the next syscall number for the
- architecture you test it on (some of you all are doing this on ARM
- systems, showoffs, and syscall numbers are not the same across all
- architectures). Document the arch you are using and why you picked
- this number in the module.
- - The syscall should take two parameters: int high_id, int low_id.
- - The syscall will take the two values, mush them together into one
- 64bit value (low_id being the lower 32bits of the id, high_id being
- the upper 32bits of the id).
- - If the id value matches your id (which of course you know as
- "7c1caf2f50d1", then the syscall returns success. Otherwise it
- returns a return code signifying an invalid value was passed to it.
- - Write a userspace C program that calls the syscall and properly
- exercises it (valid and invalid calls need to be made).
- - "Proof" of running the code needs to be provided.
- So you need to send in a .c userspace program, a kernel patch, and
- "proof" that it all works, as a response.
- This is Task 16 of the Eudyptula Challenge
- ------------------------------------------
- Good job with the new syscall. The odds of you ever having to write a
- new syscall is pretty rare, but now you know where to look them up, and
- what the code involved in creating one looks like, which is useful when
- you try to debug things.
- Let's take a breather after all of that code, and go back to doing a bit
- of reading, and learn some more about some common kernel tools.
- Go install the tool 'sparse'. It was started by Linus as a
- static-analysis tool that acts much like a compiler. The kernel build
- system is set up to have it run if you ask it to, and it will report a
- bunch of issues in C code that are really specific to the kernel.
- When you build the kernel, pass the "C=1" option to the build, to have
- sparse run on the .c file before gcc is run. Depending on the file,
- nothing might be printed out, or something might. Here's an example of
- it being run on the ext4 code:
- $ make C=1 M=fs/ext4
- CHECK fs/ext4/balloc.c
- CC fs/ext4/balloc.o
- CHECK fs/ext4/bitmap.c
- CC fs/ext4/bitmap.o
- CHECK fs/ext4/dir.c
- CC fs/ext4/dir.o
- CHECK fs/ext4/file.c
- CC fs/ext4/file.o
- CHECK fs/ext4/fsync.c
- CC fs/ext4/fsync.o
- CHECK fs/ext4/ialloc.c
- CC fs/ext4/ialloc.o
- CHECK fs/ext4/inode.c
- CC fs/ext4/inode.o
- CHECK fs/ext4/page-io.c
- CC fs/ext4/page-io.o
- CHECK fs/ext4/ioctl.c
- CC fs/ext4/ioctl.o
- CHECK fs/ext4/namei.c
- CC fs/ext4/namei.o
- CHECK fs/ext4/super.c
- CC fs/ext4/super.o
- CHECK fs/ext4/symlink.c
- CC fs/ext4/symlink.o
- CHECK fs/ext4/hash.c
- CC fs/ext4/hash.o
- CHECK fs/ext4/resize.c
- CC fs/ext4/resize.o
- CHECK fs/ext4/extents.c
- CC fs/ext4/extents.o
- CHECK fs/ext4/ext4_jbd2.c
- CC fs/ext4/ext4_jbd2.o
- CHECK fs/ext4/migrate.c
- CC fs/ext4/migrate.o
- CHECK fs/ext4/mballoc.c
- fs/ext4/mballoc.c:5018:9: warning: context imbalance in 'ext4_trim_extent' - unexpected unlock
- CC fs/ext4/mballoc.o
- CHECK fs/ext4/block_validity.c
- CC fs/ext4/block_validity.o
- CHECK fs/ext4/move_extent.c
- CC fs/ext4/move_extent.o
- CHECK fs/ext4/mmp.c
- CC fs/ext4/mmp.o
- CHECK fs/ext4/indirect.c
- CC fs/ext4/indirect.o
- CHECK fs/ext4/extents_status.c
- CC fs/ext4/extents_status.o
- CHECK fs/ext4/xattr.c
- CC fs/ext4/xattr.o
- CHECK fs/ext4/xattr_user.c
- CC fs/ext4/xattr_user.o
- CHECK fs/ext4/xattr_trusted.c
- CC fs/ext4/xattr_trusted.o
- CHECK fs/ext4/inline.c
- CC fs/ext4/inline.o
- CHECK fs/ext4/acl.c
- CC fs/ext4/acl.o
- CHECK fs/ext4/xattr_security.c
- CC fs/ext4/xattr_security.o
- LD fs/ext4/ext4.o
- LD fs/ext4/built-in.o
- Building modules, stage 2.
- MODPOST 0 modules
- As you can see, only one warning was found here, and odds are, it is a
- false-positive, as I'm sure those ext4 developers know what they are
- doing with their locking functions, right?
- Anyway the task this time is:
- - Run sparse on the drivers/staging/ directory, yes, that horrible
- code again, sorry.
- - Find one warning that looks interesting.
- - Write a patch that resolves the issue.
- - Make sure the patch is correct by running it through
- scripts/checkpatch.pl
- - Submit the code to the maintainer of the driver/subsystem, finding
- the proper name and mailing lists to send it to by running the tool,
- scripts/get_maintainer.pl on your patch.
- - Send a web link back to me of your patch in the public mailing list
- archive (don't cc: me on the patch, that will only confuse me and
- everyone in the kernel development community.)
- - If you want to mention the Eudyptula Challenge as the reason for
- writing the patch, feel free to do so in the body of the patch, but
- it's not necessary at all.
- That's it, much like task 10 was, but this time you are fixing logical
- issues, not just pesky coding style issues. You are a real developer
- now, fixing real bugs!
- This is Task 17 of the Eudyptula Challenge
- ------------------------------------------
- Another patch made and sent in. See, that wasn't so hard. Keep sending
- in kernel patches outside of this challenge, those lazy kernel
- developers need all the help they can get in cleaning up their code.
- It is time to start putting the different pieces of what we have done in
- the past together, into a much larger module, doing more complex things.
- Much more like what a "real" kernel module has to do.
- Go dig up your code from task 06, the misc char device driver, and make
- the following changes:
- - Delete the read function. You don't need that anymore, so make it a
- write-only misc device and be sure to set the mode of the device to
- be write-only, by anyone. If you do this right, udev will set up the
- node automatically with the correct permissions.
- - Create a wait queue, name it "wee_wait".
- - In your module init function, create a kernel thread, named of course
- "eudyptula".
- - The thread's main function should not do anything at this point in
- time, except make sure to shutdown if asked to, and wait on the
- "wee_wait" waitqueue.
- - In your module exit function, shut down the kernel thread you started
- up.
- Load and unload the module and "prove" that it works properly (that the
- thread is created, it can be found in the process list, and that the
- device node is created with the correct permission value.) Send in the
- proof and the .c file for the module.
- Be sure to keep this code around, as we will be doing more with it next
- time.
- 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.
- This is Task 19 of the Eudyptula Challenge
- ------------------------------------------
- Handling delayed work is easy now, right? So, time to move on to
- something totally different. How about networking? We have been
- ignoring that part of the kernel, so let us now focus on the network
- side of the kernel, as that is a huge reason for why Linux has taken
- over the world.
- For this task, write a netfilter kernel module that does the following:
- - monitors all IPv4 network traffic that is coming into the machine
- - prints the id to the kernel debug log if the network traffic stream
- contains your id.
- - properly unregisters you from the netfilter core when the module
- unloads.
- Test this by sending yourself an email with your id in the subject, much
- like the email you need to send back to me.
- Send in the proof and the .c file for the module.
- This is Task 20 of the Eudyptula Challenge
- ------------------------------------------
- Networking filters turned out to be not all that complex in the end,
- great work with that.
- So, here's the final task.
- There might be other tasks that get created and sent out later on, but
- the original challenge had 20 tasks, so after finishing this one, you
- can consider yourself done!
- Let's try something a bit harder. Something that might cause some data
- loss on a filesystem, always a fun thing to play with, if for no other
- reason than to not be afraid of things like that in the future.
- This task requires you to work on the fat filesystem code:
- - Add an ioctl to modify the volume label of a mounted fat filesystem.
- Be sure to handle both 16 and 32 bit fat filesystems {hint!}
- - Provide a userspace .c program to test this new ioctl.
- That's it! Seems so simple, right? I wonder why that option isn't in
- the kernel tree already...
- Anyway, provide a patch to the kernel, and the .c file used to test the
- new ioctl, as well as "proof" of this working. Make sure you don't run
- into 32/64bit kernel issues with the ioctl, if you do things correctly,
- you shouldn't have any problems.
- I recommend doing this work on either a loop-back fat filesystem on your
- "normal" filesystem, or on a USB stick. Either will work just as well,
- and make things easier to debug and test.
- Watch out for locking issues, as well as dirty filesystem state
- problems.
- Best of luck!
Advertisement
Add Comment
Please, Sign In to add comment
Advertisement