Liuw’s Thinkpad

m-x flush-lines
^$

在某处看到一篇文章，使用grep来找回没有分区表的硬盘中的文本文件内容。基本命令是：

grep "keyword" /dev/DEVICE

有可能需要加上其他的一些选项。

能这样做是因为在Unix中万物皆文件，即使没有Filesystem的信息，也可以通过bypass掉Filesystem的方法去读取block，得到raw data。

这个方法是有局限的。Filesystem处理数据时以block为单位，而多block的文件，block的分布不一定是连续的。也就是说grep也许能找到一部分数据，但是不大可能把所有的数据都找回来。当然，一个block一般是1K或者4K找回来的数据量对于一个文本文件来说也是相当可观的了。

为了证实我的想法，我做了以下的实验。

dd if=/dev/urandom of=hd.img bs=1M count=10

之所以用urandom而不是zero做输入，是为了增加数据，模拟真实的Filesystem。

losetup hd.img /dev/loop0

把这个文件连接到loop0，成为一个设备。

mkfs.ext3 -b 1024 /dev/loop0
mount /dev/loop0 /mnt
echo -e "This is a small file for testing.\nsecond line\nthird line" > /mnt/f1
umount /mnt

建立block大小为1024的ext3分区，然后挂载，向里面写入少量数据（少于1个block）。

grep --binary-files=text -z "file" /dev/loop0

不用-z的话，只会grep一行。

这样确实可以看到原来文件的内容。假如文件修改过有几个版本的话，可能还可以看到几个版本的内容。也许这是一个提高Filesystem效率的措施。

再测试大于1 block的文件。

perl -e 'print "string1 " x 128; print "string2 " x 128' > /mnt/f2
perl -e 'print "string3 " x 128; print "string4 " x 128' > /mnt/f3
for i in `seq 4 9`; do echo "$i" > "f$i" ; done
perl -e 'print "paddin" x 128' >> /mnt/f2
perl -e 'print " ssssss " x 128' >> /mnt/f2
...

上面其实进行了很多操作，这里就不一一列出了。block大小为1K，用stat可以看到它们的I/O block。之所以做多个文件，是为了防止ext3 bitmap在再次分配block的时候分配连续block，模拟真实环境。写完文件之后记得sync或者umount，把cache都flush到硬盘上。

再grep一次，可以发现各种数据是夹杂在一起的。

所以，最好还是注意保护自己的Filesystem吧。这些技巧只能解决小问题。

近來比較少寫blog，實在是比較忙。用繁體寫是因為看簡體的字多了眼花，得換換口味了。

72pines的頁面很奇怪，假如我不用搜狗的全網加速功能去開，出來的頁面就沒有樣式了。可能它有一部份的伺服器被教育網墻掉了（？）。

在王亮先生的Emacs定制和擴展中，找到一個“能獲取root權限的輔助腳本”，解決了我一直頭痛的一個問題。原理挺簡單，使用TRAMP來完全的。以前一直以為TRAMP主要是用于遠程編輯文件的，沒有發現這個功能，沒仔細看Manual的後果。

(defun wl-sudo-find-file (file dir)
  (find-file (concat "/sudo:localhost:" (expand-file-name file dir))))

當然，其他的內容也很精彩。

第二個，是從Wowubuntu得來的三手信息。爲什麽說是三手呢，因為它也只是轉載的。主要是講Bash shell的一些奇技淫巧。

最牛B的 Linux Shell 命令 系列连载，有點標題黨了，呵呵。

比較有趣的是活用history功能的條目，比如說sudo執行前一條命令是：

$ sudo !!

兩個嘆號“!!”等價于“!-1”，數字換成其他也是可以的，不過誰記得了那麼多啊。

另外一個有趣的功能就是Bash的替換（原來它也有啊，呵呵）：

$ !!:s/foo/bar/

很熟悉的語法，只是從來沒有想到過還有這個功能，sigh。

文章提到上面兩個技巧都是出自The Definitive Guide to Bash Command Line History。

還有一些其他的技巧，不僅僅限於Bash本身，不一而足。由於有的要么知道了，要么對我自己用處不大，這里就不多記了。

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。

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

换了一台新机器去做TPM硬件驱动的开发，于是从远程仓库把代码clone下来。试着把代码编译一次，出问题了，满版的错误，费点时间看了一下，其实是stddef.h没有找到造成的。

新机器和原来的机器都是一样系统，工具链也是一样的，代码也已经在我原来的机器上编译通过了。用find找了一下stddef.h，在机器上也是有的。仔细对比了一下通过和不通过的CFLAGS，发现不通过的情况下，头文件路径中没有gcc的包含路径，问题就出在这里了。

再看Makefile，gcc路径是通过如下的方法取得的。

GCC_INSTALL = $(shell gcc --print-serarch-dirs | sed -n -e 's/install: \(.*\)/\1/p')

使用sed匹配了以install开头的行。

但是，我现在这个系统的locale是中文的，所以“install”没有出现，取而代之的是“安装”，匹配不成功，GCC_INSTALL就成了空值，那么也没有把路径加入。

追踪了半天，没想到是locale出了问题。因为我原来一直用的是英文系统，所以没有遇到过这种情况。所以以后装系统，最好还是用英文的locale，不是说崇洋媚外不喜欢中文，要是遇到我今天的情况，估计还是挺恶心的，看着满版的错误，挺郁闷的。