The kernel folks should invest some work into an automated testing framework, one which allows you to run the tests without booting into the kernel. While automated tests, e.g. unit tests, won't make the problem go away, they are incredibly useful for realizing that your own changes to the code break some other part of it.
Actually, I'm a bit surprised that things do work so well without unit tests even though hardly anyone understands the entire kernel. With code of that complexity, usually when you pull at one end, something breaks at the other end. I guess the reason why the dev process still works so well is the intensive peer review of patches.
With the complex interdependencies within the kernel, writing test cases is certainly a challenge. For example, writing a case which tests the scheduler's behaviour in a certain situation won't be easy. But once a "scheduler test framework" is in place, it can be used for future work on the scheduler, so the work will pay off IMHO.
Copyright © 2017, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds