Liuw’s Thinkpad

I’ve been reading Linux Device Drivers 3rd for quite a long time, and once built a sacrifice system in VMWare. After I upgraded VMWare, the sacrifice kernel hangs, unable to discover root filesystem. It seems to be a driver issue. No matter how I compile my kernel, it hangs at the same place.

I finally give up, I don’t want to waste my time any more. Maybe I should just dump that 2.6.10 and try new ones. No need to

I have a Debian system working as my development system. I just need to install kernel header to get a module building environment.

# apt-get install linux-headers-`uname -r`

When it’s done, build directory should be found in

# ls -d /lib/modules/`uname -r`/build

Here is a handy Makefile for modules.

obj-m += hello.o

all:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules

clean:
        make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean

Pete Zaitcev gives the following summary:

• If you are in a process context (any syscall) and want to lock other process out, use a semaphore. You can take a semaphore and sleep ( copy_from_user* or kmalloc(x,GFP_KERNEL) ).
• Otherwise (== data can be touched in an interrupt), use spin_lock_irqsave() and spin_unlock_irqrestore().
• Avoid holding spinlock for more than 5 lines of code and across any function call (except accessors like readb).

Read the rest of this entry »

I used to find some papers on Read-Copy Update mechanism, but I didn’t quite get the point, that the Updater is sure that no reader will hold a reference to old data when all CPU has been scheduled at least once so that the Updater can safely reclaim the old data.

I found the answer in Linux Device Drivers 3rd edition, as quoted.

On the read side, code using an RCU-protected data structure should bracket its references with calls to rcu_read_lock and rcu_read_unlock. as a result, RCU code tends to look like:

struct my_stuff *stuff;

rcu_read_lock();
stuff = find_the_stuff(args…);
do_something_with(stuff);
rcu_read_unlock();

The rcu_read_lock call is fast; it disables kernel preemption but does not wait for anything. The code that executes while the read “lock” is held must be atomic. No reference to the protected resource may be used after the call to rcu_read_unlock.

[...snip...]

All that remains is to free the old version. The problem, of course, is that code running on other processors may still have a reference to the older data, so it cannot be freed immediately. Instead, the write code must wait until it knows that no such reference can exist. Since all code holding references to this data stucture must (by the rules) be atomic, we know that once every processor on the system has been scheduled at least once, all references must be gone. So that is what RCU does; it sets aside a callback that waits until all processors have scheduled; that callback is then run to perform the cleanup work.

As the bold text mentioned above, RCU is working mostly by the rules.

$ indent -kr -i8 -ts8 -sob -l80 -ss -bs -psl