diff -u：内核开发的新项目

译至：http://www.linuxjournal.com/content/diff-u-whats-new-kernel-development-1

Linux的一个问题是它的系统调用实现 。 正如Andy Lutomirski日前指出的，它非常的混乱。 他说，甚至确定哪些系统调用是为哪个架构所实现也是非常困难的，因为需要识别调用名和编号的映射关系，以及调用参数寄存器和系统调用参数之间的映射关系。一些用户程序如 strace 和 glibc 需要知道这类信息，但是他们收集这些信息的方式  -- 虽然很好完成了，但也是非常的凌乱。

安迪建议通过苦读内核代码，写一个文本文件作为系统调用的“主列表”，给出调用名，相应的调用号，支持的体系结构和其他的信息。 别的不说，这将允许像glibc这样的工具去消除它们那丑陋的实现并使用一个简单的库来从内核之外获取这些信息。

H·Peter Anvin喜欢这个主意，但表示，这将花费了很多工作来让它正确运行。 他提到，他一直主张沿同一路线一直一去，这可以追溯到他在klibc上工作。

其他人也喜欢安迪的想法 -- 特别是那些到需要自己去整理系统调用来实现用户代码的人。 大卫·豪威尔说，如果使用strace也可以依靠安迪的主列表，这将是极其美妙的。 而且， Michael Kerrisk说， 手册项目也有兴趣跟踪主列表的进度。

总有一种特殊情况受益于进程调度的调整。 近日，来自Oracle的哈立德·阿齐兹提交了一些代码，允许用户进程要求额外的时间片。 通常，内核本身控制这种资源分配，因为不然的话该系统将依赖于用户应用程序的友好性或良好的编码。

但是，哈立德的数据库同事也注意到一个问题，大量的线程争用同一互斥量。 如果这些线程中的一个获取了互斥量并准备放弃时，调度器可能会遍历所有其他进程的队列，但它们中没有一个可以实际运行的，因为他们都在等待同一个互斥量。这就很麻烦了，持有互斥量的进程被设置为放弃但却不能放弃，因为它已被抢占。 哈立德说，情况会好的多，让持有互斥量的进程延迟抢占，让它有足够长的时间去放弃互斥量。 然后所有的其他进程能轮到它自己来做实际工作，而不是花自己宝贵的时间片在不可用的锁上忙等。

哈立德说，他的代码显示相对于之前的情况下加速了3-5％。 但是，仍然一些意见不愿意接受他的代码到内核中。

特别是，H. Peter Anvin指出，哈立德的代码允许用户空间程序将内核自有的抢占式多任务变换成协同式多任务模式，在该模式中所有的进程都必须必须同意谁能够得到时间片，何时一些进程能在损害其他进程的同时积极地获取时间片。

Davidlohr Bueso指出，自愿抢占模型允许进程自愿放弃自己的时间片给另一个进程，可以与现有的内核实现更好地工作。没有来自敌对的进程的危险。

针对哈立德的设计有各种替代品的建议，但哈立德始终指出，他的方式是最快的。 不过， Thomas Gleixner说，“这是一个可怕的想法。你正在创造的是以水晶球软件为基础的时间绑定的优先级，上层提供的是我见过的最糟糕的用户空间接口。”

显然，这是真正的问题。 给用户空间的代码可以抢占正常调度进程的能力意味着内核和其他用户空间进程无法预测系统的行为，甚至无法适当地调试问题。

托马斯一度说道，“你正在试图做的事基本上是创建一个ABI，我们要永远支持和维护这个ABI。这绝对是一些严重的问题。” 他补充说，“如果我们因为你的数据库负载而允许你的特殊情况，那么我们就没法去争辩，为什么我们不应该为实时的工作负载做同样的事情，其中SCHED_FAIR守护线程可以短暂持有锁来获得一些在SCHED_FIFO实时计算线程里的重要的数据。当然RT的人想避免锁竞争如你所做，只是为了不同的理由。“

埃里克·W·毕得曼也反对哈立德的代码，他说道：“你允许任何任务延长其时间片，这意味着我会有这样一个问题，在sched_preempt_using_job任务运行时，为什么really_important_job错过了时间保证？” 他说：“你的改变似乎已经极难调试非本地的影响。”

似乎很多人有兴趣去实现像哈立德提出的功能，但看起来也有人关注安全问题，关注可调试性和可维护性，这使整个事情变得很不确定。 但是，哈立德仍然可能解决这些问题，并想出了一个补丁来实现数据库的需要，而没有那些乱七八糟的。