百毒不清

一边总结2011的十大任务完成情况一边展望未来，2011的任务有贴为证——http://www.baidubuqing.com/node/221

1. 2011的第一个任务：不看美剧，改看电影，争取去电影院看20次电影（同一个电影看多次也计数）。
超额完成任务：武林外传，关云长，蓝精灵*2，功夫熊猫2，变形金刚3，加勒比海盗4，速度与激情5，哈利波特7下*2，金陵十三钗，龙门飞甲，失恋33天，肩上蝶，源代码，里约大冒险，丁丁历险记，永无止境，一夜迷情，美国队长，窃听风云*2，猩球崛起，雷神，五月天追梦3dna，铁甲钢拳，辛亥革命，海洋，白蛇传，画壁，建党伟业，武侠*2，鸿门宴，希望没遗漏。
完成情况: 1.7
2012的第一个任务：看电影好像是没啥意思了，改为k歌吧，争取20次。

2. 2011的第二个任务：争取写完一篇中篇，若有心，一年一篇就足够了。
把binder驱动写完了。。。orz，伪技术文也算吧。
完成情况: 1.0。
2012的第二个任务：争取填完一个坑，这次必须是小说了，伪技术文滚蛋，不能算数。不文艺就二逼。

3. 2011的第三个任务：增肥到80kg
刚刚好70kg。。。
完成情况: 0.5。
2012的第三个任务：体重诚可贵，运动更重要。明年要运动了，争取10次羽毛球吧。不敢定20次。。。

aaa

by Nefarius@newsmth.net
有些事情是结束不了了，不过这个文章还是可以结束的。如果没记错的话，还剩fd和death notify没写了。赶紧写完睡觉。
fd是通过offsets数据里的类型BINDER_TYPE_FD传递的，driver会根据src的fd，在target proc中找一个空闲的fd，然后install上，都是file的一些基本操作。懂的人一看就明白，不懂的人要想真明白的话还是先看看kernel里关于file的部分。而我，属于不明白的，所以这部分就不详细写了，因为binder驱动里关于file的操作其实真的不多。不过跨进程传fd很重要，没有它就没有ashmem, pmem, IMemory, ImemoryHeap等等等等，结果会很悲剧的。
而death相关的涉及到以下几个BC/BR:
BC_REQUEST_DEATH_NOTIFICATION,
BC_CLEAR_DEATH_NOTIFICATION,
BC_DEAD_BINDER_DONE
BR_DEAD_BINDER
BR_CLEAR_DEATH_NOTIFICATION_DONE

BC_REQUEST和BC_CLEAR是相反的命令，一个要求死亡通知，一个是移除死亡通知。死亡通知是记录在binder_ref的death字段，death指向结构体:

by Nefarius@newsmth.net
终于可以写引用计数了，赶紧填完这个坑。
列一下驱动里涉及到binder引用计数的BC和BR：
1. BC_INCREFS, BC_ACQUIRE, BC_RELEASE, BC_DECREFS, 进程主动要驱动增加/减少计数。
2. BR_AQCUIRE, BR_INCREFS, BC_AQCUIRE_DONE, BC_INCREFS_DONE，驱动要进程增加引用计数以及进程完事之后回复驱动。
3. BR_RELEASE/BR_DECREFS, 驱动要进程减少引用计数。
4. BR/BC_ATTEMPT_ACQUIRE, BR/BC_ACQUIRE_RESULT, 这四个没实现。

写之前简单介绍一下binder驱动和binder库的对应关系。一个进程里如果是自己的指针或者说是类，在驱动里叫做binder_node，在binder库里对应于BBinder，如果是别的进程的指针或者说是类映射到自己的空间里，驱动里叫做binder_ref，在binder库中对应于BpBinder。而android本身又搞了一套RefBase/sp/wp的东西来做引用计数，这个是通用的，并不仅仅是对binder使用的，于是事情就稍微复杂了。

by Nefarius@newsmth.net
上回说的transaction里还有个没提到的，就是binder_buffer以及BC_FREE_BUFFER。

稍微回顾一下binder里的数据相关结构体。
ioctl BINDER_WRITE_READ使用的是binder_write_read，里面的write_buffer/read_buffer都是用户空间的地址，这里面可以存放多个BC/BR，而每种BC/BR的附带数据都是固定大小的。在这里面，BC_TRANSACTION/BR_TRANSACTION/BC_REPLY/BR_REPLY将携带附加的transaction参数，结构为binder_transaction_data。

binder_transaction_data里面的data.ptr包含buffer/offsets两个指针，分别指向存放普通数据以及跨进程数据(binder/fd)的用户空间地址。

by Nefarius@newsmth.net

最近很无聊，决定把以前的坑填完。先把这个binder驱动的写完吧，其他的坑慢慢填。
已经写过三篇了，binder驱动的基本东西，binder驱动的数据结构，binder驱动的进程线程。前面几篇文章每次提到一个writerread，后面必然跟了一句“以后再写”，这次真的不能以后再写了，现在就写。

BINDER_WRITE_READ是binder里最重要的ioctl，通过它，用户程序可以发命令(BC_开头)给驱动，也可以从驱动读出回复(BR_开头)。这些BC/BR大概可以分为四类，一类是线程池相关的，上一篇已经写过了，各种LOOPER的BC和BR，一类是引用计数相关的，一类是死亡通知相关的，这两类看来还得以后再写，还有一类就是transaction相关的，包括BC_TRANSACTION, BC_REPLY, BC_FREE_BUFFER, BR_TRANSACTION, BR_REPLY, BR_DEAD_REPLY, BR_TRANSACTION_COMPLETE, BR_FAILED_REPLY，对于上层应用的使用者来说，这个是最重要的，这个也是binder实际目的所在——不同进程之间的通讯。这篇主要写这个ioctl以及重要的transaction。

唉，一直以来莫名其妙得对hr有畏惧感，看来是有道理的...有些事真的就是没缘分啊。
来贵司一年多了，数数kill的hr们...
刚入职没没几天，发offer给我的hr离职了。
过了段时间，一个我看着她入职的hr离职了。
又过了段时间，当初通知我面试的hr离职了。
然后就是杯具的事情。
正准备找一个hr帮忙办点事，该hr离职了。
找接班的hr帮忙，等该hr放完假，也离职了。
临走时，她说会有个新人接手，正在交接任务。
我查了查，我勒个去，该新人还没入职！！！
那么，该新人hr究竟会不会入职呢？
唉，我只能四目以待了。
希望这回不会kill一个还没入职的hr。
上帝保佑！

第一次听说《思凡》，应该是看一班人演话剧《思凡》，不然便是看一班人看电影《霸王别姬》，总之是与一班人脱不了干系的，但此文却是与一班人没有干系的。
《思凡》里我记且仅记住的一句话是：小尼姑年方二八，正青春被师傅削去了头发。
这句话里，二八一词是十六还是二十八呢，那得取决于试图去记住它的人是个萝莉控还是个御姐控。很不幸，我是个御姐控，所以在我看来二八是二十八，而我今天恰好也被师傅削去了头发。可惜的是，老衲不是小尼姑，所以老衲没法思凡，只能丝烦。
这个丝是特指的我头上的那根白头发，说它是未老先衰的凶兆呢，它却又能顽强的在我的屠刀下一次次长了出来，看上去又是生命力旺盛的雄兆。搞得我心里很乱，剪不断长还乱，拿它一点办法都没有，烦不胜烦。只好用小尼姑的话“年方二八正青春”来自慰了。

睡觉真是一件痛苦的事情啊，八点半上床，十点了还没睡着。

记得张震（如果我记错了的话，道个歉先）在某个娱乐节目中被问道最关注女人的哪个方面，长相还是身材。他说，年少的时候最关注长相，大了点之后就关注身材了，现在最关注的是皮肤。

对于长相和身材很好理解，大部分人的前半生基本上都是与同龄人一起度过的。年少的时候，男人在那个时候还不会用下半身思考，而女人在那个时候也没有让人用下半身思考的资本，所以身材不会是关注点，至于皮肤，女人在那个时候都是不分伯仲的，自然也不会是关注点，于是关注长相便是一件很自然的事情。

随着年龄的增长，下半身的思考能力以及诱惑都在不断的增强，对身材的关注度就会越来越高，直到某一天，男人最终摆脱了关注长相的惯性思维，此时，身材便成了最关注的东西。

不过，我一直没明白张震最后为何会最关注皮肤。直到最近看《法证先锋3》才隐约有所体会。

当男人渐渐习惯了用下半身解决问题后，用下半身解决问题的新鲜感就越来越低，用下半身思考问题的新鲜感也就越来越低。而且男人们会发现很多时候自己只能思考问题却无法真正去解决问题，男人们便会开始反思，把决定权交给下半身是不是一个错误。于是关注权又慢慢的回归到了上半身。

A:我这个人很喜欢走极端，所有的事情不是0就是1，除了感情。
B:奥，原来你很喜欢暧昧。
A:......跟你灌水真没劲，其实我想说的是，感情问题上，我一般都是很2的。