Christian Schoenebeck wrote on Wed, Nov 04, 2020: > > Greg, Christian - from what I understood (in private, hopefully I'm > > allowed to repeat!), he won't be able to contribute to qemu because of > > company policies and I'm unlikely to take the time either right now. > > I don't think it's a problem to continue as is though, we can land linux > > kernel support (it's still useful for non-qemu servers) and if someone > > is interested later on they'll just need to finish that bit. > > Hmm, no idea what kind of policy that is; there is no GPL3 in qemu at least > that some companies are concerned about, but OK not my business. > > I actually thought this would still take a while on kernel side,
To be honest, so did I -- the original patches are so old I had more or less given up on it :P But I don't see any more problem now and we'll want to get there eventually so now's a good time as any... I just want to get fault injection to work to test various refcounting cornercases but shouldn't be much longer. > so in the > meantime we layed the ground in qemu for resolving this issue independent of > clients and independent of any guest OS installation by introducing test > cases > using the 9pfs 'local' filesystem driver: > > https://github.com/qemu/qemu/blob/master/tests/qtest/virtio-9p-test.c > > So the idea was to resolve that chicken egg problem of this issue that way > and > also handle it a bit more systematically. If you now run qemu's 9p tests with > latest git version (or at least with yesterday's QEMU 5.2 rc1 tarball): > > cd qemu/build > make > export QTEST_QEMU_BINARY=x86_64-softmmu/qemu-system-x86_64 > tests/qtest/qos-test > > these tests will now create a test directory qtest-9p-local-XXXXXX under the > current directory (i.e. the build directory) where they are creating real > directories and files like on a production system would do, just without a > guest OS. > > As you can see, there are already 9p tests for creating and deleting > directories, files, symlinks and hard links, etc. > > Maybe somebody interested to see this issue resolved in qemu might help by > rebasing Greg's old patches and testing it with some test cases this way. > Personally I need to work on some other things in the next couple weeks, but > if somebody needs help, questions, review, etc., I'll be there. Great news, nice work there. I see the new tests it doesn't look hard to add new ones reproducing open-unlink-fstat for example; I think it's good to have regardless of kernel progress. We'll get there! -- Dominique