> > Regarding the testing - we ran WHQL networking tests on the device. > > If we provide the logs will it be sufficient? I believe the test > > coverage is much more comprehensive than anything that we will do with > > qtest. > > I'm not sure I'd agree about comprehensive
Let's just say that passing WHQL can easily be months of work. > As you've seen from this thread, there's no a tremendous amount of > interest in supporting this device. That's your opinion. Personally I would be very glad to help getting the vmw_pvscsi device in QEMU via the SCSI tree, and I don't see why VMXNET3 should be different. > 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. We can talk again when QEMU has: * libos bindings for at least PCI and the APICs, perhaps the 8259 too, and examples of how to use those; * mocks for network devices (block device mocks are needed too, but not for this device of course). I helped moving qtest forward hoping that other people (like Stefan is doing, and like Andreas did for QOM) would contribute other pieces of the infrastructure. I certainly would have spent my time otherwise, had I known that the immediate outcome was making QEMU development slow and unwelcoming due to unreasonable prerequisites for contributing new devices. Certainly it is not reasonable to expect infrequent contributors to do our homework. Paolo