Development and Debugging

Due by 11:59 PM on Sunday, Nov 08

Building the kernel

We have to make some modifications to the way we build the kernel. You can generally focus the same steps you have been doing so far. However, once you get to the make xconfig step, you have to enable a few extra options. If you want assistance in debugging your locks you will need to enable the lockdep module. It is very important to not leave any related code in your final submission. More on that in the debugging section.

In order to enable the lockdep module, scroll all the way to the end of the xconfig window. Navigate to Kernel hacking > Lock Debugging and enable the following:

Lock debugging: prove locking correctness
Lock usage statistics
Lock dependency engine debugging
Sleep inside atomic section checking
Locking API boot-time self-tests

You can see the following image for clarification:

You should also go to Kernel hacking > Compile-time checks and compiler options and select Install uapi headers to usr/include. By doing this, the installation process will add the required headers so you can use the mailbox_id_t data type in user space for your tests!

Alternatively, if you do not do the above step you can execute the following command once you have built your kernel: make headers_install INSTALL_HDR_PATH=/usr. You should run this command from your project3-part2 directory.

Development

You should be good to go for your kernel space development. However if you want to write tests, you need access to the mailbox_id_t datatype. If you followed either of the instructions above you should have a header you can include from user-space as follows:

#include <linux/mailbox_421.h>

If you are getting an error that gcc could not find that header for your user-space program, it means you didn’t do one of the two steps at the end of the building section above.

Debugging

If you have enabled the options we told you to in the building section, you should have access to the lock debugging utilities. The interesting thing with lockdep, is that if it encounters an error it stops any subsequent reporting. The reason is that the first error could be causing the rest of the errors. The problem lies in the fact that the 1st error might not be coming from your code. The Guest Additions module has such an error for example. In order to re-enable the debugging you need to do the following:

In mailbox_421.c include the following headers:

#include <linux/debug_locks.h>
#include <linux/atomic.h>

And then in mbox_init_421 have the following line as your first line:
```
xchg(&debug_locks, 1);
```

Information of the day: The xchg function is almost the same as the test_and_swap instruction you might have seen in your book

It is very important to remove the above code in your final submission. If you leave it in, your kernel will fail to compile when we are building it !

Now you should be able to see the lockdep output in dmesg, just like you did for your printk. Do NOT attempt to use printk in your critical sections. Do NOT attempt to use printk to debug your locks. It will not work, it will not do what you want it to do.

If you can, you should increase your vm core count to at least 2.