Liuw's Thinkpad

Good question!

答案是：一点也不难。随便打开一个文件，然后找出comment里面的拼写及语法错误，再然后按照使用Git发送patch提到的方法发送出去就ok了。一般都可以被ack然后进仓库的。

这是一个很严肃的事情哦，为社区做贡献。门槛也不高，值得一试。:-)

当然，前提是要会用Git以及有一本好词典，呵呵。

以前我一直很土地手写patch邮件，今天Ian Campbell教了新招数，先记下来。Git的send-email可能要单独安装（我的Debian就是）。

首先要安装好MTA，我现在用的是exim，看自己喜好了。然后Git的配置文件要写好。

[user]
        name = OOXX
        email = XXOO
[sendemail]
        smtpserver = SMTPSERVER
        chainreplyto = false
        signedoffcc = true

Patch要排版怎么办？没关系，用git format-patch。然后使用git send-email就OK了。

% git send-email $(git format-patch HEAD^..) --to XIAOMING --cc XIAOHONG --bcc XIAOFANG

注意由于前面signedoffcc设置的缘故，邮件会自动抄送patch里面所有sign off了的人。

慢着，写个Linux内核补丁，不知道该往哪发，怎么办？内核hacker们早就帮我们想好了。

% cd LINUX_KERNEL_DIR
% ./scirpt/get_maintainer.pl PATH_TO_YOUR_PATCH

运行之后会出来一些地址，有list和maintainer，尽管发就好了。

到今天为止，到Cambridge正好一周了。今天从B&B guest house搬到了新住处，终于可以拿点时间出来记一下目前的情况。总之，很多事情都是要分两面看，哪样好哪样不好，还是得看个人喜好了。

周一的时候就自己出去买了个地图把Cambridge转了一下，真是小得可怜。City center也就那么一小块，一个小时就可以转个遍。出了city center周边，除了主干道那就是荒无人烟了。公共交通贵，没什么娱乐活动，即使是city center一带，晚上8点也不怎么见到人了。然后晚上除了去Pub，基本也没什么其他活动。当然自然环境是没得说的，大学的历史也摆在那儿，可以说是一个整体很适合居住的地方。

出行的基本方式有三种：开车、骑自行车和坐公交。公交实在是很令人无语，贵不说，在市外还半天不来，所以真不是一个很好的选择；车便宜，二手的最便宜的几百镑就有，加之前面说的公共交通的特点，所以开车的人很多；骑自行车很流行，一是健康，二是省钱，三还比较自由，所以骑车的人也很多，但是自行车贵，也容易丢。

总的来说，Cambridge的生活节奏很慢，压力也不是很大。对于平时习惯了快节奏、高压力的中国IT人士（比如我）来说，反而一下会不大适应。周六的时候和朋友一起到market place吃午饭，旁边坐一老大叔，一边喝咖啡一边吟诗（不清楚是不是），真是雷死我也。人都很有礼貌，sorry、thanks、cheers常挂嘴边。一切都井然有序，很多事情都要appointment，从正面来看就是办事都很有规矩不用求爷爷告奶奶，从反面来看过多的条条框框使得效率比较低下。这个国家现在已经是高度文明了，这是一个很吸引人的地方，但是从活力上来说，给我的感觉和国内还是比较有差距的。

再来说说工作。地点在Cambridge Science Park，离市区不远，但是步行的话那是万万不行的。Office是7×24开放的，上班不打卡，随时来都行——我都不清楚要怎么考核员工了。Kitchen里面有无限量的coffee、milk、tea、cookie和有限的几种水果（没办法，贵），貌似晚上还有简单的晚餐和宵夜；Kitchen旁边还有一些简单的娱乐设施。周边没有任何的商店，所以吃饭是个很大的问题。现在Engineer里面都有tradition了，比如说周一叫个印度外卖，周二出去吃泰国快餐，周三吃墨西哥快餐啥的，每天也有sandwich van来做生意，总的来说品种还算丰富。

娱乐方面，Prof. Raj早就提醒过我：“Cambridge不大适合年轻人。”当时我还多少有点不以为然。现在看来，除了去Pub，根本就没有其他的活动了，不可能像国内一样去吃个什么街边摊、唱歌之类的。去Pub的话其实也很尴尬，语言和文化是很大的问题；但是social life的场合本身就少，想要和同事打成一片，不去那又不行。还好，Cambridge是一个比较国际化的地方，所以总体来说大家都是“外人”，也都会体谅其他人的一些语言和习惯上的问题。

目前只能说so far so good。这个国家还有很多值得我去了解的地方。打算是work hard play hard，打算是每个周末去英国的各个地方转转；要是能办下申根签证，那就更加好了，用12天假期去欧洲再转一圈。

陆陆续续地也有一些感兴趣的人发邮件来问VirtIO on Xen的情况，所以还是写一篇文章来解释一下这个项目的后续情况吧。

虽然我也写了一篇文章说明进一步开发VirtIO on Xen需要完成哪些工作。但是我认真想一下之后，这个项目应该还是不大会继续开发的了——也就是说，在那些toolstack的patch进去之后，后续开发的实用价值已经不是很大了。再具体点说，就是VirtIO on PV目前还是有一些无法克服的困难，具体的问题在前面的文章有提到。这些困难虽然目前是已经workaroud掉了，但是却是不能向上游反馈的，因为这些workaround已经break many things了。

所以对VirtIO on Xen的最后的想法，就是要在HVM里面用还是可以的，PV就最好不要用。一方面实现得比较差，另外一方面那些patch也是无法upstream的。

刚才在MindHacks上看到了一篇新鲜出炉的文章《怎样花两年时间去面试一个人》，谈“招聘难”。那篇文章从招聘的角度去谈问题，其实在我这个应聘求职者的眼里来看，找工作也绝对不是一件易事。

不是说有没有offer的问题，而是我个人对于工作的事情非常慎重（甚至我自我感觉太慎重了点）。想多了，甚至想到人生终极目标上去了（笑）。现实点的话，那么我希望是可以把我的个人理想和社会责任结合起来。

我的梦想很多，但是我也明白，选择一条路的时候，其实就是放弃了其他的路。也许只有真正搞清楚自己心里需要的东西，才可以坦然地选择。朋友们给了我很多意见和建议，我很感谢他们，但是最终的决定，还是要靠自己。自己的人生，必须自己负责。

长这么大第一次来魔都。交通很便捷，我从武昌火车站到目的地，大部分时间都是在轨道交通工具中度过。先是火车，然后是地铁。这近一千公里的行程，就在逼仄的车厢中消磨过去了。从我自己的感觉来说，这样的旅程少了很多乐趣。在地铁没有这么发达的城市，公共汽车是市内交通的首选，城市的形象随着公交车外的风景而丰满，更加活色生香，期间更穿插着担心搭错车、坐过站的刺激感，而路人对问讯的回应，也是这个城市的一个缩影。

自己出门在外，这也不是第一次了，其实也没什么这么多感慨的。上初中一年级的时候，曾经自己从南宁坐车回家，感慨也没这么多。反正就是上车下车的事，照着行程走就是了。反而是长大之后就喜欢发起感慨来。每个城市都不一样，都有自己的特色。从我仅有的上海地表之行来看，上海的城市环境很不错，有蓝天，有绿地，很合我的心意。不过上海话确实是一句都听不明白。

扯远了。这次上海之行的真正目的，其实是拜访一家创业公司（至于到底是干啥的，暂时保密，哈哈）。这是一家真真正正处在startup阶段的startup，不像我以前参观拜访的另外一家，已经到扩张阶段了，所以看到的东西确实也很不一样。这段时间，对于选择什么样的工作，我想了很多，也尝试去学习和了解一些我原来不清楚的事实。

创业公司谈的是对时势的判断，对未来的判断。从历史的角度来看，每个时代都必然会产生一定的成功者。我们现在艳羡的大公司，只是成功在那个时代做大做强了而已，而其他的一些公司则如大浪淘沙一般，消失在历史的长河中了。假如现在还有人谈用微软模式打败微软、用腾讯的模式打败腾讯，我会觉得这是一件很可笑的事情。只有用新模式，才有可能颠覆旧模式；用旧模式去挑战旧模式的强者，必死无疑。

新模式在哪里？大家都知道，大家又都不知道。就像现在大家都知道移动互联网会火，但是谁也不清楚到底一个什么样的模式会让自己成为这个时代的王者。大方向谁都会吹，但是实在地践行自己的想法，又是另外一回事了。在思考实践的过程中，其实也是险阻重重。

创业公司的最开始的团队，必须都有比较高的技术水平，这个是毋庸置疑的。但是，创业公司最根本的财富，是整个团队有着同样的目标，对于自己所做的事业保持信心，甚至说转化成为一种信仰。创业是很艰辛的，艰辛之处除了技术上的问题之外，更多的还是未来的不确定性。

关于创业公司和大公司的对比，网上已经有太多的论调，我想我已经不必再赘述。哪一个更加合适，应该是因人而异的。

以上为上海之行的收获，晚上的车回武汉，等车的时候写点东西排解一下无聊。

下面的文字是由Ian Campbell的邮件整理出来的，还有一些我自己的想法和查到的资料。

现在Xen netback的基本工作模式还是copying model，也就是说前后端数据交换的时候不是zero copy的。IanC目前正在向上游反馈skb paged fragment desctructor补丁，这系列补丁可以让backend对guest RX做grant mapping，从而实现zero copy。在copying model上进行后续工作意义不大。

紧接着就是一系列的重构。

目前的模型是driver domain的每个VCPU配置一个netback worker，这些netback worker在多个VIF之间共享。打算改为每个backend配置一个netback worker。在进行这样的改进时必须要注意内存的使用情况，原来的model中内存的使用基本是固定的，新model由于worker数目和backend数目相关，所以要有一定的扩展性。可以考虑使用内存池来防止worker过多导致内存消耗过大的问题。但是初步实现的话，静态内存分配也是可以接受的。

内部接口改用NAPI，这项改进依赖于前一项。大部分设备的TX completion都比较廉价，所以NAPI使用中最大的开销就是RX。但是切换过去之后（NAPI使用tasklet），就要考虑VCPU是否会过载（这也是目前还使用thread的原因）。这一部分需要仔细的测试。

再接下来的工作依赖于NAPI。

Receiver (guest) side copy，说得太模糊，不大清楚IanC的意思。

Multiple queues for TX and RX，这个可能和Stefano提到的VMDQ有关，把dispatch的的任务offload到硬件（原来是软件的bridge）。现在Intel的万兆网卡已经提供支持了，在VMWare上实现及测试的结果是有4x吞吐量约有1.3x的提升（4->9.2）。

除了上面的一系列想法之外，还有一个相对独立点的改进——netback对SR-IOV的支持。

想法很多，目前也不系统，先列一下，留待后用。

大概是9月2日到校，粗略到今日算是一个月了。写一篇为blog除除草。

这个月，没有写任何有意义的代码，因为忙着做很多事情。找工作是一个大头，对于大多数学生来说还算比较有意义，所以这里还是重点记录一下吧。

到放假之前，拿到的offer有三个——有一个已经有确切的待遇，另外两个是节后通知。还有一家公司还差最后一面。今年的公司普遍来得比较早，估计是公司对人的需要是越来越多的了，这对于我们学生来说是个好事，因为这就可以多点机会多点选择。但是我其实是很被动的，因为我原来打算九月做其他的事情然后复习一下题目，到十月份旺季的时候正好准备完。计划被打乱了，所以只有硬着头皮上了。

有两家整个过程还是比较好的，因为自己一直在做那方面的事情，所以就算没有刻意去准备也没有什么大问题。倒是第三个公司的面试只面了一面，面试感觉也不是特别好，没想到也给我发了offer，所以自己也觉得有点意外。面试完后，面试官很坦诚地和我讲“你做题真是做得挺差的”，我也很坦诚地说“是啊，我也觉得自己不是做题的料，加之没有时间准备，做得不好”。但是面试官有一点还是比较看得起我的，他觉得我对技术比较有热情，沟通能力还不错，人也不笨（当然可能也因为有朋友的美言）。也许就是因为这些因素，他给我过关了。

倒是这个offer带给了我思考。我一直在想，我的核心竞争力在哪里。技术是会变的，行业也是会变的。作为一个新人，不能好高骛远，还是踏踏实实地培养自己的基本能力为好。作为计算机专业的学生，我觉得算法、数据结构、系统架构等很多东西都是要掌握的（可惜很多方面我还很差）。作为一个年轻人，我觉得最核心的竞争力就是对待事物的热情、克服一切困难的冲劲和对任何事物都持有新鲜感（我觉得这方面做得还不错）。

各种各样的面试真的很好玩。虽然开始的时候可能会紧张，但是进入状态我就可以滔滔不绝地讲，讲自己的想法，讲自己怎么去做这个事情，同时也去了解面试官的想法，了解公司的需求，了解业界的观点。这样的面试，就算被刷掉，我也不会觉得有什么遗憾，因为我觉得我得到了比一个offer上的数字更加实在的东西。记得曾经面试过某公司的运维实习，一面的时候我和面试官的角色几乎调了过来，真是聊得很爽，只是最后还是没有去，浪费机会了（罪过罪过）。

这一个月，面的公司不多，但是基本都是自己感兴趣的。每个行业有一家（虽然我的职位没什么不同），目前的结果也还好。记下来给自己一点勉励。

This post should have finished a long time ago. Sorry folks, I don’t know if I really have time to finish what I left over, but it is really necessary to write it down so that someone (me?) will pick it up and move on…

I wrote some of my thoughts in Xenwiki’s VirtioOnXen page. However, those items are high-level and abstract. Now I will explain my TODOs for the second iteration.

* Enable Xen mapcache for Virtio for PV

The prototype has very bad exec implementation. For every READ/WRITE to memory, it first maps DomU’s memory, then r/w, then unmaps it. A single operation will cause two page table updates. That’s not ideal.

However it is not easy to enable mapcache in PV case. Xen’s PV memory model is quite different from HVM’s. Xen mapcache is originally designed for HVM and tightly coupled with QEMU – it is stubbed into cpu_physical_memory_rw. It is not easy to unify HVM and PV memory model (is it really possible?) and reuse cpu_physical_memory_rw.

What I can see to get this done is first we should re-factor the mapcache to de-couple it from the existing code. Then we can use the mapcache for PV exec.

* Squash two evtchns into one, eliminate locking

Currently two evtchns are used in the transport layer. One (evtchn1) for transport layer notification “be I need to control the device” (FE->BE), the other (evtchn2) is for backend notification telling drivers “hey, you have data waiting” (BE->FE).

Some may wonder why do we need two in the first place. All I can explain is that I want to emulate the behavior of Virtio in HVM’s case, that is synchronous “trap-process-return”. PV cannot really “trap”, it can only spin wait for a common variable (or a bit). With these two evtchns, locking is necessary, because “process” may trigger evtchn2, to which a IRQ handler is bound. That re-activates DomU from a different code path, and the transport layer never gets a chance to “trap” again.

So, how does squashing evtchns help producing lock-free code? We abandon evtchn2 and introduce a bit to indicate notification. We can defer data processing to work queue. This is how xen-pcifront and xen-pciback work.

To achieve this goal, we need to first introduce bitops into QEMU, because we have two bits now: BE acks FE’s control request and BE tells FE there is something waiting in the ring. These two bits must be handled in strict order, I would not go deep here, see xen-pcifront and xen-pciback for details. After introducing bitops, we can start re-factoring the transport layer, which should be easy.

* Enable Virtio device DMA capability

Don’t know if this is upstreamable, but I think it is worth trying. Virtio is designed for hardware-assisted virtualization, it holds an assumption that backend from the device’s point of view (say, qemu-kvm) can access the same address space as CPU does. However, in real world, devices don’t always have the same view as CPU does.

In order to create memory space consistent across CPU and backend, use of DMA API is necessary. Unfortunately, Virtio device doesn’t response correctly to DMA API (because they don’t have to, given the assumption mentioned earlier). So in current code, the ring is allocated by DMA API with NULL device, which is bad practice.

This task may not be trivial. Coding doesn’t require much effort. What concerns me most is keeping Virtio intact. If we are to alter simple kmalloc into DMA API, we have to change a lot of its design and internal too.

I swear that I’ve tried my best to explain my minds. To fully understand my decisions, you may have to read the fxxking code. :-)

从回学校开始就一直在为各种各样的事情忙碌，原本和朋友许诺的一些技术post也没有动手写。按照目前的情况，折腾到10月底是必须的了。

走，还是留，真的是一个问题。目前所有我遇到的人都希望我出去。而我有时傻乎乎地想，出去多个经历不也挺好的吗。心大心小，终于还是踏上了这一条路。Peter和我说，出国一般是要提前半年，像我这样的情况直接出去，简直凤毛麟角。Citrix那边倒是一切OK，application form说一声就发过来了，但只怕我这次又要折在签证上了。不得不吐槽一下中国国籍真不值钱。

为什么现在还这么有闲情上来写blog呢，其实是实在已经没有什么可以做的了，进入一个听天由命的状态。有时候晚上想很多，睡不着，早上起来心里却很空，就像摔到谷底了一样。也经常自我安慰，出不去，在国内找个工作也可以的。有时也在想，既然开始了，那就坚持到底吧，自己能有今天，也不是一直坚持的结果吗。心情就像坐过山车，忽高忽低。

总归看过几本心理学的书，知道自己现在不正常，需要调节。但是又有什么好办法呢？一边找工作，一边搞签证，一边做实验室的事情，一边顾及自己的生活。每天task list上urgent的事情一堆，而且相互之间又是错综复杂的关系，一心四用，累。

现在找工作放不开手脚，各路朋友的好意也不敢轻易接受，怕浪费；签证半死不活；实验室事情追得紧，总要给个交待；生活貌似也一团糟糕。别人看我是不紧不慢，志得意满；但是自己心情真的是如人饮水冷暖自知。

罢了罢了。上来吐槽一番，虽然没有解决什么实际问题，心里却舒服了点。我知道也有少数几个关心我的朋友订阅了我的blog，只能对大家说起对不起了。心大心小，也总不是个办法。HX就说我选择太多，所以痛苦。到十月份，让所有事情都来个了断吧！