On Tue, 30 May 2023, Kent Overstreet wrote: > On Tue, May 30, 2023 at 05:00:39PM -0400, Mikulas Patocka wrote: > > I'd like to know how do you want to do coverage analysis? By instrumenting > > each branch and creating a test case that tests that the branch goes both > > ways? > > Documentation/dev-tools/gcov.rst. The compiler instruments each branch > and then the results are available in debugfs, then the lcov tool > produces annotated source code as html output. > > > I know that people who write spacecraft-grade software do such tests, but > > I can't quite imagine how would that work in a filesystem. > > > > "grep -w if fs/bcachefs/*.[ch] | wc -l" shows that there are 5828 > > conditions. That's one condition for every 15.5 lines. > > Most of which are covered by existing tests - but by running the > existing tests with code coverage analylis we can see which branches the > tests aren't hitting, and then we add fault injection points for those. > > With fault injection we can improve test coverage a lot without needing > to write any new tests (or simple ones, for e.g. init/mount errors) I compiled the kernel with gcov, I ran "xfstests-dev" on bcachefs and gcov shows that there is 56% coverage on "fs/bcachefs/*.o". So, we have 2564 "if" branches (of total 5828) that were not tested. What are you going to do about them? Will you create a filesystem image for each branch that triggers it? Or, will you add 2564 fault-injection points to the source code? It seems like extreme amount of work. Mikulas
