2.漫谈兼容内核之二：关于kernel -win32对象管理.pdfVIP

漫谈兼容内核之二: 关于kernel-win32 的对象管理 毛德操 近来屡有网友提到一个旨在将Wineserver 移入内核的开源项目kernel-win32 ；有问及其 本身，希望能对其代码作一些分析、讲解的，也有问及兼容内核与此项目之间关系的。所以 从这篇漫谈开始就来谈谈kernel-win32 。 首先，兼容内核项目应当从所有(能找到的)相关开源项目吸取营养，有时候甚至就采取 “拿来主义”，反正都是开源项目，只要遵守有关的规定就行。从这个意义上说，我们对于 kernel-win32 肯定要借鉴，也可能要“拿来”一些。但是这种借鉴和拿来的取舍必须以客观 的分析为基础，必须与我们的终极目标相一致。相信读者在看完从本文开始的几篇漫谈以后 就会明白我为什么把Wine 、ReactOS 、和NDISwrapper 列为兼容内核的三个主要源泉，而没 有把kernel-win32 也列为主要源泉之一。 从总体上说，kernel-win32 把原来由Wine 服务进程提供的某些功能和机制移入了Linux 内核，具体(就目前所见版本而言)有这么一些： 1．文件操作。 2 ．Semaphore 操作。 3 ．Mutex 操作。 4 ．Event 操作。 5 ．作为同步手段的WaitForMultipleObjects()系统调用。 所有这些机制和功能的实现都有个共同的基础，那就是各种内核“对象(Object) ”及其 Handle 的实现。由于已打开的对象是属于进程的资源，又由同一进程中的所有线程所共享， 所以又跟进程、线程的实现和管理有关。 此外，kernel-win32 也提供了比Wine 更高效的RPC 机制，用以提高应用进程与Wine 服务进程通信的效率。 但是kernel-win32 的实现并不完整，甚至并不构成局部的完整性，而且已经实现的部分 恰恰是相对而言难度并不高的部分，所采取的方案也还值得推敲。 特别地，kernel-win32 的目标只在于提高Wine 的效率，所以并不涉及设备驱动。与兼 容内核的终极目标相比，二者只是在一小段路程上有“同路”的关系。以我们的眼光看， kernel-win32 无疑是朝正确的方向上在走，但是走的毕竟太近。 Kernel-win32 的代码大体上分成三个部分。第一部分是对于Linux 内核代码的补丁，在 它的kernel 目录下。第二部分是它本身的代码，是要作为module 动态安装到内核中去的， 具体的代码文件都在它的根目录下。第三部分是一些测试/演示程序，这是作为应用软件在 Wine 上运行，或者部分地绕过Wine 、与Wine 并行的，特别是其中还包括一个用于启动系 统调用的库程序win32.c ，这些程序都在它的test 目录下。从逻辑上说，库程序win32.c 属于 kernel-win32 ，而测试/演示程序则不是；就好像Linux 的内核与libc 都属于Linux ，而用来 测试/演示其功能的程序却不算一样。此外，为了帮助调试，代码中的 strace 目录下还包括 了对 Linux 的一个调试工具 strace 的补丁与扩充。这个工具可以用来跟踪应用软件所作的 Linux 系统调用，实时地显示所跟踪的应用软件进行具体系统调用时的参数和内核的返回值。 这对于调试当然大有帮助，但在逻辑上也并不是kernel-win32 的一部分。 下面我从kernel-win32 的代码入手，对它的方方面面作一简要的介绍和分析，本篇先说 kernel-win32 的对象管理，即Object 和Handle 的实现，实际上也必然会牵涉到进程和线程。 Object 和Handle 的实现 我曾经讲到，Linux 把设备看成文件，所以“文件”是个广义的概念；而Windows 又进 一步把文件看成“对象(Object) ”，“对象”是个更广义的概念。而标志着已打开对象的“句 柄(Handle) ”，则虽然在物理意义上与“打开文件号”相似(实质上都是下标) ，却有着许多不 同的特性，因而不能把二者混为一谈。为了把Linux( 内核) 的文件系统机制“嫁接”到Windows 的系统调用界面，必须为每个运行着Windows 应用的进程(下称“Windows 进程”或“W