diff -u: Detainting the Kernel
What's new in kernel development: detainting the kernel.
Sometimes someone submits a patch without offering a clear explanation of why the patch would be useful, and when questioned by the developers, the person offers vague or hypothetical explanations. Something like that happened recently when Matthew Garrett submitted a patch to disable a running kernel's ability to detect whether it was running entirely open-source code.
Specifically, he wanted to be able to load unsigned modules at runtime, without the kernel detecting the situation and "tainting" itself. Tainting the kernel doesn't affect its behavior in any significant way, but it is extremely useful to the kernel developers, who typically will refuse to chase bug reports on any kernel that uses closed-source software. Without a fully open-source kernel, there's no way to know that a given bug is inside the open or closed portion of the kernel. For this reason, anyone submitting bug reports to the kernel developers always should make sure to reproduce the bug on an untainted kernel.
Matthew's patch would make it impossible for developers to know whether a kernel had or had not been tainted, and this could result in many wasted hours chasing bugs on kernels that should have been tainted.
So, why did Matthew want this patch in the kernel? It never was made clear. At times he seemed to suggest that the patch was simply a way to avoid having users complain about their kernel being tainted when it shouldn't have been. At one point Ben Hutchings suggested that Matthew might want to allow third parties to sign modules on their own for some reason.
But as no one was able to get real clarity on the reason for the patch, and as tainting the kernel is traditionally a good way to avoid chasing down bugs in closed-source code, none of the developers seemed anxious to accept Matthew's patch.