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. 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_ Marc PS: according to Dan, the test code in the kernel should also have more build-time checks like the ones in nvdimm/config_check.c but that's not mutually exclusive at all and IMHO a separate topic.
