A few comments on the test (explained in the git commit log): ----
[PATCH] canonical: convert ndctl/test into qa-regression-ndctl tests ## good tests (bad results mean something) blk-exhaust.sh btt-check.sh btt-pad-compat.sh label-compat.sh multi-dax.sh rescan-partitions.sh sector-mode.sh dax-ext4.sh dax-xfs.sh ## TODO: needs more work. locking/unlocking nvdimms using keyutils security.sh ## TODO: do a merge proposal to debian fio pkg enabling pmem engines device-dax-fio.sh ## TODO: enable this tests by compiling "test/" directory (next phase) mmap.sh monitor.sh ## alignment issues (full ns boundaries not aligned, TODO: smaller ns might work) create.sh ## needs injection (error or smart) and qemu nvdimm emulation does not support it btt-errors.sh clear.sh daxdev-errors.sh inject-error.sh inject-smart.sh pfn-meta-errors.sh pmem-errors.sh ## qemu nvdimm is pmem_compat (dax-class instead of dax-mode) daxctl-devices.sh ## Expected output: ~/ndctl/test$ ./regression.sh test ./blk-exhaust.sh: succeeded test ./btt-check.sh: succeeded test ./btt-pad-compat.sh: succeeded test ./label-compat.sh: succeeded test ./multi-dax.sh: succeeded test ./rescan-partitions.sh: succeeded test ./sector-mode.sh: succeeded test ./dax-ext4.sh: succeeded test ./dax-xfs.sh: succeeded ## Expected return code: 0 = All tests have succeeded 1 = A test has failed (check /tmp/regression.log) Signed-off-by: Rafael David Tinoco <rafaeldtin...@ubuntu.com> ---- # security team Please note that, security wise, you're probably interested in the security.sh test. It uses keys to lock/unlock nvdimm devices (an interesting feature for 20.04 I suppose). I'm not entirely sure the emulated nvdimms will be enough for this test to run BUT I can help you after all this has been placed somewhere and is up and running. # other todos: i might be able to fix the TODOs here but I'm trying to be careful on how much time Im spending on this (balancing with other things for 20.04). @Christian: Do you think this patch could be put as a delta for ndctl/test directory ? I'm thinking in supportability in the next years to come. Keeping it out of the source package might make it hard to either extend it and/or fix changes. Note: ndctl/test is not used for anything in binary packages, it would just be in the source packages. I could even add those as debian/tests for autopkgtest, and skip tests if being ran in a machine that doesn't support nvdimms (even suggesting to Debian). Thoughts ? PS: I'm pretty sure with those tests we're able to maintain this and catch regressions regarding PMEM-based block devices being accessed with DAX and/or through MMAPs (having the mmap tests fixed would be also beneficial). For now I'm considering this done, missing only a place to merge this. Thank you! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/1853506 Title: [MIR] ndctl To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/ndctl/+bug/1853506/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs