On 1/18/23 18:20, Shinichiro Kawasaki wrote: > CC+: Mike, dm-devel, > > Hi Chaitanya, thanks for bringing this up! I definitely want to join and learn > from the discussions. Here I note my comments about them. > > On Jan 18, 2023 / 23:52, Chaitanya Kulkarni wrote: > [...] >> For storage track, I would like to propose a session dedicated to >> blktests. It is a great opportunity for the storage developers to gather >> and have a discussion about:- >> >> 1. Current status of the blktests framework. > > In the session, I can talk shortly about recent blktests improvements and > failure cases. > >> 2. Any new/missing features that we want to add in the blktests. > > A feature I wish is to mark dangerous test cases which cause system crash, in > similar way as fstests does. I think they should be skipped by default not to > confuse new blktests users. > > I remember that dmesg logging was discussed at the last LSFMMBPF, but it is not > yet implemented. It may worth revisit. > >> 3. Any new kernel features that could be used to make testing easier? >> 4. DM/MD Testcases. > > I took a liberty to add Mike and dm-devel to CC. Recently, a patch was posted to > add 'dm' test category [1]. I hope it will help DM/MD developers to add more > tests in the category. I would like to discuss if it is a good start, or if > anything is missing in blktests to support DM/MD testing. > > [1] https://lore.kernel.org/linux-block/20221230065424.19998-1-yukuai1@xxxxxxxxxxxxxxx/#t we really need to sort out the dm testcases, without dm testcases it not allowing us to create baseline correctness for block layer, I've already discussed that in the last LSF. > >> >> E.g. Implementing new features in the null_blk.c in order to have device >> independent complete test coverage. (e.g. adding discard command for >> null_blk or any other specific REQ_OP). Discussion about having any new >> tracepoint events in the block layer. >> >> 4. Any new test cases/categories which are lacking in the blktests >> framework. > > One thing in my mind is character device. From recent discussions [2][3], it > looks worth adding some basic test cases for NVME character devices and SG > devices. > Agree -ck
