3 ms·

> That doesn't mean that something nasty couldn't have been lurking all these weeks, of course What percentage of what sections/components of the kernel are co

> That doesn't mean that something nasty couldn't have been lurking all these weeks, of course What percentage of what sections/components of the kernel are covered by some kind of CI/CD-equivalent test? Compile it, load it into qemu, do a sanity check... Obviously that's useless for drivers. The remark was written in a way that doesn't inspire much confidence? lol I'm just it's just being silly but I also know that it isn't like a normal codebase where you strive for 95% unit test coverage or whatever.

klysm 4y ago
I’m somewhat convinced that simple line coverage is not a particularly useful metric in such a dynamic system. When there’s so much concurrency and layers of stateful behavior, the value of a condition simply being executed is diminished.
sillystuff 4y ago
No idea if this is representative, but apparently 15K lines of test code were added just for id mapped mounts (before id mapped mounts was merged to mainline). > Brauner added that there are 15K lines of code in tests, already upstream in fstests, for ID-mapped mounts that aim to test the feature in all possible combinations. That includes things like access-control lists (ACLs), Linux capabilities, setuid and setgid execution, and so on. Every time a bug or regression is found, a new test is added to the suite. https://lwn.net/Articles/896255/ https://lwn.net/Articles/896255/ (just happened to read this LWN article immediately before reading your comment)
viraptor 4y ago
Not sure what the percentage is, but you can find what's being tested in the testing guide https://www.kernel.org/doc/html/latest/dev-tools/testing-overview.html https://www.kernel.org/doc/html/latest/dev-tools/testing-ove... , the linux test project https://linux-test-project.github.io/ https://linux-test-project.github.io/ and few other places. Maintainers of drivers usually test those.

klysm 4y ago

I’m somewhat convinced that simple line coverage is not a particularly useful metric in such a dynamic system. When there’s so much concurrency and layers of stateful behavior, the value of a condition simply being executed is diminished.

sillystuff 4y ago

No idea if this is representative, but apparently 15K lines of test code were added just for id mapped mounts (before id mapped mounts was merged to mainline). > Brauner added that there are 15K lines of code in tests, already upstream in fstests, for ID-mapped mounts that aim to test the feature in all possible combinations. That includes things like access-control lists (ACLs), Linux capabilities, setuid and setgid execution, and so on. Every time a bug or regression is found, a new test is added to the suite. https://lwn.net/Articles/896255/ https://lwn.net/Articles/896255/ (just happened to read this LWN article immediately before reading your comment)

viraptor 4y ago

Not sure what the percentage is, but you can find what's being tested in the testing guide https://www.kernel.org/doc/html/latest/dev-tools/testing-overview.html https://www.kernel.org/doc/html/latest/dev-tools/testing-ove... , the linux test project https://linux-test-project.github.io/ https://linux-test-project.github.io/ and few other places. Maintainers of drivers usually test those.