变化的一天

还是昨天的问题，上午和相关的人一起讨论了一下吗，还是只有一条路可走，为TM单独出一个lib，为他单独管理共享内存。经过我们的一再“挖掘”，TM的leader也总算是像我们解释清楚了为何他有这个特殊的需求：TM的两个process之间共享一大块的内存，初始部分是一个结构体，这个结构体里面含有指针。在进程A里面指针的值是A的，要想在B能正常解析出这块内存的内容，就必须使得它在A和B虚拟空间中attach的地址是一样的。HP是能够保证的，但是linux上却没有这样的承诺。所以需要我们的库提供这样的功能。其实这种共享的方式是不对的，正确的做法应该是使用偏移量。

中午和同事对调了下位置，感觉这边很失败，周围的人都不是同一个组的，并且感觉融入进去很难，没意思。

下午继续弄这个问题，一开始不想改变A/B，只是将重新编译的库刚在原来库的前面，这样应该是能使得他们调用新库的，但是测试的时候发现了其他的问题，似乎不行。明天有时间仔细测试一下，可能是其他的原因导致的。发现的一个问题还是很多。后来在新库里面重新定义了下接口名字，同时改变A/B的调用和编译依赖，后来也只是勉强跑通了新库，真正的测试明天才能弄。进展不大，部分原因是测试的过程中没有做好记录，搞得后来都弄不清楚没次失败时的状态是什么了。另外一个是测试新库的时候搞乱了内存还是什么东西，使得我们的系统老是起不来，我记得是讲共享内存全部删除了的，但是也没有时间深究，只是重启系统了事。这个过程中碰到了一些问题，这里记下来，日后可以查验下：

1）库的引用名字是在编译的时候定好了的，单纯改编译后的库文件的名称并不起作用。比如A用到一个库libux_v1.sl，ldd查看使用时的库名称是libux.0（链接），将库文件改为libux_v2.sl，重新编译A以后，它实际上还是引用的libux.0。这个不带版本号的link是为了增加系统的灵活性，不同的版本库都可以使用一个库的引用名字。因为我这里要引用新库，但是原来的库还得用，所以我开始以为将新库放到和A同一个目录下就可以了，连链接都忘了建（基本功不扎实，好在后来醒悟了）。后来建立了链接又不对，因为我用原来的名字连接到新库，导致其他的应用都用了我的新库，直接搞死系统；

2）mmap的效果子进程会继承。所以在原有库里面reserve的pages范围在A/B依然起作用，导致在A/B里面要保存的地址开始地址要相应地往上偏移。这个通过配置环境变量可以比较轻松搞定；

3）用ldd A可以看到所需要的库都被找到了，但是我们的系统在起A的时候却报告无法找到新库。我检查了LD_PATH(全名忘了)，发现路径都在里面，这个还没有弄清楚原因，都算是周末的工作吧