> The bits I'm more interested about is edge case testing (things that > could pose a security concern). Since WHQL interfaces at the expected > paths for the driver, it's unlikely that it can test any of this.
It does include fuzz tests. > >> But VMXNET3 isn't really special here. From this point forward, I > >> would expect all new devices to come with a qtest-based test case. > > > > I find this to be hard to justify. > > > > With a grand total of 1 device tested, and with a coverage of almost > > zero even for that device, I think it's only sane to consider qtest > > a proof of concept. > > How else are we going to get there other than asking people to use it? I agree. But I'm saying it's too early even for that. > Look, it's pretty darn simple to add a basic test for vmxnet3 to qtest > that initializes the device. I don't see what the big deal is asking for > that. For that, qemu-test is enough. Just boot into a Linux system that has the driver. > It doesn't need to start as an exhaustive test but I think there's > tremendous value in at least having something to start with. Otherwise, > we'll continue to exist in the same chicken and the egg state. Yes, that's a risk. I guess you were aware of that though. I've long planned to contact again my academic friends, ask for a bachelor student or two and have them work on QEMU. qtest would be perfect for that (libos and a decent block layer mock would be two nice projects). However, mentoring can be time consuming, and right now I'm not really able to set aside time for that. Paolo
