Aiur – ZelluX 的技术博客

VMware支持虚拟串口设备，对于调试内核或者虚拟机的帮助很大，具体设置如下（VMware Server 2, Xen 3.3）：

1. VMware中为虚拟机增加串口设备
Add Hardware->Serial Port，然后在设置中将Connection模式设为File，指定相应的文件路径(如[standard] debian-xen/serial-port.log)

2. 修改虚拟机的grub启动参数，以我的/boot/menu/lst为例

title           Xen 3.3.0 / Debian GNU/Linux, kernel 2.6.18.8-xen
root            (hd0,0)
kernel          /boot/xen-3.3.0.gz com1=115200,8n1 loglvl=all guest_loglvl=all console_to_ring console=com1,vga sync_console
module          /boot/vmlinuz-2.6.18.8-xen root=/dev/sda1 ro console=tty0
savedefault

3. 重启虚拟机，即可在之前指定的文件中(Host机上的/opt/vmware/Virtual Machines/debian-xen/serial-port.log)中看到虚拟机的输出信息了。

参考文章：

[1] http://hokietux.net/blog/?p=58
[2] http://scie.nti.st/2007/11/14/hosting-git-repositories-the-easy-and-secure-way
[3] http://www.nkuttler.de/2009/04/06/git-clone-ssh-could-not-resolve-hostname/

1. git

很简单，直接用pacman安装即可
sudo pacman -S git

2. gitosis

gitosis是一个方便管理git仓库的工具，安装方法：

1) 从yaourt或者aur下载安装gitosis-git包 http://aur.archlinux.org/packages.php?ID=23419

2) 新建git用户
sudo useradd –system –shell /bin/sh –comment ‘git version control’–user-group –home-dir /home/git/ git

3) 将开发用户的rsa公钥导入gitosis，（没有公钥的话请先运行ssh-keygen -t rsa生成）
sudo -H -u git gitosis-init < ~/.ssh/id_rsa.pub

4) 如果以上步骤没有问题，那么运行
git clone ssh://git@hostname/gitosis-admin.git
后应该就能看到gitosis-admin.git这个目录了

5) 新建项目、添加用户等操作参见[2]，这里不再赘述

3. gitweb

事实上ArchLinux中安装的git包自带了gitweb，可以用which gitweb搜到，一般默认在/usr/share/gitweb。下面假设我的http根目录为/home/httpd

1) 将/usr/share/gitweb下的文件复制到/home/httpd/cgi-bin（其实似乎只要gitweb.cgi就够了）
sudo cp -R /usr/share/gitweb /home/httpd/cgi-bin/

2) /usr/share/gitweb下的.css和.png复制到/home/httpd/html/git/

3) 修改或创建/etc/gitweb.conf，具体配置如下

# git命令的地址
$GIT = "/usr/bin/git";

# 项目仓库地址
$projectroot = "/home/git/repositories";

# 网页显示相关的文件，我把它们都放在了/home/httpd/html/git/下
$stylesheet = "/git/gitweb.css";
$logo = "/git/git-logo.png";
$favicon = "/git/git-favicon.png";

# 首页显示的站点名
$site_name = "ZelluX's Git Trees";

# 项目信息中显示的地址，
@git_base_url_list = ("ssh://git\@hostname");

# 网页中项目说明的显示长度
$projects_list_description_width = 50;

# 发布的项目的标记。例如/home/git/repositories/hello/git-daemon-export-ok存在，
# 那么hello这个项目就会显示在项目列表上。
# 但是似乎每次pull或者push操作都会导致git把这个它认为多余的文件删掉，不知道有没有其他的解决方案。
# 把这行注释掉就允许所有的项目显示在网页上。
$export_ok = "git-daemon-export-ok";

$feature{'pathinfo'}{'default'} = [1];

$feature{'blame'}{'default'} = [1];
$feature{'blame'}{'override'} = [1];

$feature{'pickaxe'}{'default'} = [1];
$feature{'pickaxe'}{'override'} = [1];

$feature{'snapshot'}{'default'} = [1];
$feature{'snapshot'}{'override'} = [1];

$feature{'search'}{'default'} = [1];

$feature{'grep'}{'default'} = [1];
$feature{'grep'}{'override'} = [1];

4) 在apache的配置中增加以下内容 /etc/httpd/conf/httpd.conf，这里我没有用VirtualHost机制，只加了行URL重写规则，VirtualHost的配置方法参见[1]

RewriteEngine on
RewriteRule ^/gitweb/(.*) /cgi-bin/gitweb.cgi/$1 [L,PT]

5) 重启apache后应该就能访问 http://hostname/gitweb/ 了，如果提示Project not found，请确认apache能访问git的仓库目录，并且相应的项目目录下有git-daemon-export-ok这个文件。

Multi-Execution: Multicore Caching for Data-Similar Executions

这篇paper针对以multi-execution这种模式运行的程序提出了一种新的cache手段。

所谓multi-execution，指的是同时运行同一个程序的多个进程，而它们的输入数据又互不相同。这种模式在machine-learning领域比较常见，一些相对独立的learner可以以并行的方式被训练，而它们的结果可以通过一种叫做boosting的方式合并起来。给我的感觉似乎有点像mapreduce？

然后呢，作者们发现以这种方式运行的程序进程的数据有很大一部分是相同的，在合并cache数据上可以做一下文章，节省cache的使用。

于是这篇paper提出了一种叫做mergeable cache的架构，用于代替传统的L2 cache，L1 cache还是传统的cache架构。首先假设相同的数据的虚拟地址往往也是相同的（应该去掉了address space randomization的影响），以类似Page Coloring的策略进行物理页的分配，使得不同进程同一虚拟地址所对应的物理页都是相邻的。然后把虚拟地址的头9位作为cache tag，再为每个cache line记录一个bit vector用以表示某个processor的数据是否保存在这条cache line中。于是L2 cache hit当且仅当：
1. 虚拟地址的头9位等于cache line的tag
2. cache line中的bit vector的processor对应的位被置上

另外为了简化cache策略，L1和L2的数据内容是互斥的，或者说一段被cache的数据要么在L1，要么在L2，不可能同时存在于两者中。这样一来L2就只有从L1淘汰出来的数据了，而L2中的数据修改分三步完成：
1. 把数据从L2中标记为不存在（对应processor的bit vector位置0）
2. 数据进入L1
3. 修改数据

这就是这篇paper提出的cache架构的主要内容，后面的evaluation部分做的也很不错。从数据中可以看出合并的cache里面dirty cache占了比较大的比例，从而说明简单的copy-on-write策略的效果不会很好，因为copy-on-write只能合并clean cache。最后平均的speedup提升在2.5x左右，很不错。但是对于数据无关的并行程序运行，会产生一定的overhead，此时可以选择传统的L2 cache机制。

读Multi-Execution (ISCA ’09)的时候看到的名词，中文叫做高速缓冲器页着色，有点拗口，还是用英文术语好了

早期的处理器缓存都是映射虚拟内存的，这样带来两个问题，一是进程切换等场合下需要清空缓存，二是由于多个虚拟地址可能指向同一个物理地址，因此会出现缓存中数据别名的问题(data aliasing)。

于是现代的处理器更多的通过物理地址进行数据缓存，这也引入了另一个问题，虚拟内存中看到的相邻的两块数据在缓存中很有可能是不相邻的，如果操作系统分配物理页时不考虑这点就会影响性能。

举例来说，假设CPU能缓存4个物理页，缓存策略是CSAPP中提到的最简单的方式，即第n号缓存只用于物理页号除4余数为n的物理页(n=0,1,2,3)，比如第2号缓存对应于2,6,10,..号页面。现在用户为页面号为0的虚拟页申请空间，操作系统把第16号物理页分配给它；接下来用户又为页面号为1的虚拟页申请空间，而17-19号物理页已经用掉，此时操作系统就不应该分配20号物理页给它，因为20号物理页和16号物理页占用同一个缓存地区，假设用户程序的局部性(locality)很好的话这样的分配方式会产生比较严重的抖动(thrashing)，影响系统缓存的性能。所以操作系统应该分配21号物理页给它，而保证这种分配策略的方式就是为每个页标记不同的颜色，并使得同一时间使用的页面颜色尽可能的不同。

参考资料
http://en.wikipedia.org/wiki/CPU_cache
http://www.freebsd.org/doc/en/articles/vm-design/page-coloring-optimizations.html

吴总讲的一篇paper，题目是Orchestra: Intrusion Detection Using Parallel Execution and Monitoring of Program Variants in User-Space，发在EuroSys ’09上，UCI的。

这篇paper提出了一种检测栈上buffer overflow攻击的方法。想法很有意思，它运行两个孪生进程，这两个进程的唯一的区别就是一个进程的栈往上长而另一个进程的栈往下长，这样在大多数情况下如果没有出现buffer overflow的问题的话那么两者的行为应该是一致的。

栈的增长行为是由编译器控制的，作者修改了gcc的代码使之生成的代码的栈增长方向相反，关于这个编译器他们之间发过一篇paper在一个叫CATARS的workshop上，题目是Reverse stack execution in a multi-variant execution environment。

“行为一致”的精确定义是两者的system call的调用方式、参数都一样，也就是说这里system call成了两个进程运行的synchronization point。如果某个点上两个进程调用的syscall不同或者调用参数不同就认为它已经被buffer overflow攻击了。

整个monitor都是跑在user态的，主要利用了ptrace，使两者的行为尽可能的一致。这里要做的事情很多，比如要保证进程调用getpid()的得到返回值一样才能使得后面的其他系统调用的参数相同，又比如一个进程调用write写入文件时不能影响到另一个进程，此外还要保证两个进程获得的file descriptor、随机数、时间、信号等信息都相同，甚至在进程创建子进行的时候也要保证所有子线程关系的同构。

用ptrace能够解决上面的大多数问题，但还有一些open problem以及false positive。如这篇paper无法解决进程用MAP_SHARED方式打开一个文件并修改的情况，尽管作者说这种mmap的用例很少见；此外由于两个进程的同步并不是原子性的，中间可能被第三方的程序干扰（比如进程A读入某个文件开头后，该文件被其他进程修改，进程B再读取就和进程A读到的不一样了），这就造成了false positive；另外由于无法截取rdtsc指令的使用，也就无法保证它们的返回值一样，也可能引起另一种false positive。

感觉这个东东想法不错，但是没什么实用性，工程量也很大。

在kernel 2.6.29上编译vmware modules时报错了

/usr/src/linux-2.6.29/arch/x86/include/asm/apicdef.h:132:1: warning: this is the location of the previous definition
/tmp/vmware-config0/vmmon-only/linux/driver.c: In function ‘LinuxDriverSyncCallOnEachCPU’:
/tmp/vmware-config0/vmmon-only/linux/driver.c:1423: error: too many arguments to function ‘smp_call_function’
/tmp/vmware-config0/vmmon-only/linux/driver.c: In function ‘LinuxDriver_Ioctl’:
/tmp/vmware-config0/vmmon-only/linux/driver.c:1987: error: ‘struct task_struct’ has no member named ‘euid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1987: error: ‘struct task_struct’ has no member named ‘uid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1988: error: ‘struct task_struct’ has no member named ‘fsuid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1988: error: ‘struct task_struct’ has no member named ‘uid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1989: error: ‘struct task_struct’ has no member named ‘egid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1989: error: ‘struct task_struct’ has no member named ‘gid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1990: error: ‘struct task_struct’ has no member named ‘fsgid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:1990: error: ‘struct task_struct’ has no member named ‘gid’
/tmp/vmware-config0/vmmon-only/linux/driver.c:2007: error: too many arguments to function ‘smp_call_function’

貌似是2.6.29的task_struct有了改动导致的，网上搜到一堆vmware workstation在kernel 2.6.29上的补丁，都不好用，最后在http://www.saarlinux.de/blog/?p=5 翻到一个已经打了补丁的vmware modules包，解压到/usr/lib/vmware/modules/source覆盖原来的几个.tar文件再运行vmware-config.pl就可以了

长时间使用Emacs经常会觉得小指疼痛，一个月前我把自己用的三台电脑（两台winxp，一台archlinux）的Caps Lock键的功能都改成了和左Ctrl一样，这样小指按起来就舒服多了，另外由于平时不需要用到Caps Lock键所以也不需要找个组合键来代替它了。

Windows下有个很方便的改键工具，xp安装盘自带，也可以从这里下载：remapkey

Linux下的改键我知道两种方法，一种是修改xorg.conf文件，把里面的键盘设备设置改成

Section "InputDevice"
Identifier      "Generic Keyboard"
Driver          "kbd"
Option          "CoreKeyboard"
Option          "XkbRules"      "xorg"
Option          "XkbModel"      "pc104"
Option          "XkbLayout"     "us"
Option          "XkbOptions"    "ctrl:swapcaps"
EndSection

另一种是使用xmodmap这个工具，具体可以参见这篇文章 Changing your caps lock into Ctrl in X，这里简单介绍下

修改前记得先备份当前的键位映射，xmodmap -pke > xmodmap.backup

接下来运行

xmodmap -e 'keycode 66 = Control_L'
xmodmap -e 'clear Lock'
xmodmap -e 'add Control = Control_L'

这样就修改了Caps Lock的键位映射而不需要重启x，如果要在每次启动时自动修改Caps Lock键的映射，可以新建/修改一个.Xmodmap或者.xmodmap的文件，在里面加入

keycode 66 = Control_L
clear Lock
add Control = Control_L