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.

In fact, a ‘^M’ in text file is a carriage return (CR), often introduced by DOS text file format. It’s possible to do a simple substitution to get rid of it.

Easiest way is to use a dedicated tool called `dos2unix’, and yes, there is a corresponding tool called `unix2dos’.

Or, we can use Vim/Emacs to convert it.

(first open file with Vim)
:set ff=unix
:set ff=dos

Or use Vim command line switches.

$ vim +"set ff=unix" +wq $DOS_FILE

In Emacs, just do a substitution. Use C-q C-m to input ^M.

# dpkg-reconfigure locales
# dpkg-reconfigure tzdata

第一个方法，最简单那当时是直接写脚本。但是那样不够灵活，每次只能执行特定的指令。

第二个方法，使用tentakel。

第三个方法，使用multixterm。

个人觉得第三个方法最好，但是也没有实际用过。这些东西都是老林问我我才查查的，没有实践，先记下了。