On the merging of ktimers
...with the exception of one observer, who has kept up a steady stream of complaints about the new mechanism. His objections include the name (he would rather see "process timers" than "ktimers"), the use of high-resolution time within the kernel, and various "unnecessary complexities." The discussion has been mostly unfruitful, to the point that the normally even-keeled Ingo Molnar tried to end it with a shut up and show me the code challenge. That led Andrew Morton to state that "show me the code" is no longer an acceptable arguing point for kernel discussions, and that the objections should be addressed regardless.
Getting a handle on the objections has proved hard; it is not clear that the person in question (Roman Zippel) truly understands the patches. One bit of the discussion is worth a look, however. It has been repeatedly pointed out that the existing kernel timer mechanism is optimized for timeouts which rarely actually expire, while ktimers are expected to expire. Roman claimed:
This claim led to a required-reading response from Ingo on the history of the kernel timer mechanism and why optimizing for delivery (or the lack thereof) is not nonsense. That particular branch of the discussion, at least, should not need to go much further.
Andrew Morton has, in the past, stated that he would be highly reluctant to
merge new code over the objections of a developer. The need to address all
objections can be highly frustrating to kernel hackers, especially when new
complaints seem to keep turning up as the old ones are resolved. The
result of this process, when it works well, can be a stronger kernel. But
it can also be the delaying of useful
code which few people have problems with. It is starting to look like that
may be the outcome in the ktimers case; the code will almost certainly be
merged in the end, perhaps with almost no changes resulting from the
current discussion.
| Index entries for this article | |
|---|---|
| Kernel | Development model |
| Kernel | Timers |