Marc Herbert wrote: > > Thanks to the patience and help from the Intel people on these lists, I > think I finally found all the CONFIG_* missing in ndctl.git/README.md > > I tested, fixed and published two CONFIG_ fragments here: > > https://github.com/pmem/run_qemu/tree/main/.github/workflows/ > > - cxl-test.cfg: CONFIG_ fragment enough for: meson test --suite=cxl > - nfit-test.cfg: CONFIG_ fragment enough for: > meson test --suite=ndctl:ndctl and --suite=ndctl:dax > > In my ideal world, these fragments would live in ndctl.git/ directly > (instead of run_qemu.git/) and ndctl.git/README.md would point at > them. This would make them _testable_ by any automation. Like this > automation: https://github.com/pmem/run_qemu/actions > > As a second best and much quicker fix, "someone" could simply add to > ndctl.git/README.md the missing CONFIG_ found in these new .cfg files > of mine.
Send that patch and I will ack it. The linked configs look good to me. > Unfortunately, that "someone" cannot be me because I don't know or don't > understand precisely what many of these CONFIG_s mean: the files in > https://github.com/pmem/run_qemu/tree/5723a592/.github/workflows/ come > from "educated" guesses and a lot of trial and error. But these fragments > pass the tests, so they're already much better than what is in the > current README.md! > > I can already tell that some of these are tricky. For instance, > CONFIG_MEMORY_FAILURE=y is required for dax-ext4.sh and dax-xfs.sh to > trigger the error message "Sending SIGBUS due to hardware memory > corruption" (more context in > https://lore.kernel.org/nvdimm/20250515021730.1201996-3-marc.herb...@linux.intel.com/T/#u) > > BUT, these tests can also pass without CONFIG_MEMORY_FAILURE=y and > without triggering that error message! So... CONFIG_MEMORY_FAILURE=y is > not required? Or, it is required but there a bug in that test? Or, > either choice is fine but CONFIG_MEMORY_FAILURE=y is better because > it provides more coverage? I don't have that sort of validation expertise > and it would take me a long time to learn it for every missing CONFIG_ The goal is to excercise memory_failure(). The fact that the test passes with memory_failure() disabled is not that interesting. Could the test be improved to fail when memory_failure() is disabled? Probably. Is that useful? Probably not. Those build time checks are just a more forceful way of ensuring the expected test environment. I think config fragments in the README are sufficient.
