Date: Fri, 31 Dec 2021 14:21:19 -0700 From: Alan Somers <asomers@freebsd.org> To: freebsd-arch@freebsd.org Subject: LGPL code in /usr/tests? Message-ID: <CAOtMX2gp46301jOA2OG8bqxDgxspqSYPafGNtxdvqyO-nk2Qtg@mail.gmail.com>
next in thread | raw e-mail | index | archive | help
I recently ran into a bug in fusefs that can only be triggered when NFS exports a FUSE file system. That makes it very difficult to write an automated test. My options are basically: * Add an fhgetdirentries(2) syscall that is like getdirentries, but takes a fhandle_t* argument instead of a file descriptor. * Actually start nfsd during the test, and export the temporary FUSE filesystem. The first option sounds like way too much non-test code to change. Plus, I may need to add thread() and fhwrite() syscalls too, for other NFS-related test cases. The second option would also be a lot of work, but at least the work would all be confined to the test code. However, what would I do once I've exported the file system? Mounting it with the NFS client would add several more layers to the stack under test. I'm not even sure that it's safe to self-mount an exported file system. Another option would be to communicate directly with nfsd from the test code. That's possible, but writing NFS RPCs by hand is very cumbersome, and it would obscure the test logic. A better option is to use libnfs. The API is just what I would need. However, it's licensed under the LGPL 2.1. I know that we as a project decided to import no new GPLish code into contrib/. But this code would never be used outside of /usr/tests, so it wouldn't even affect many production builds. Would that be acceptable? The workarounds are ugly: * Create a new port for all libnfs-dependent tests. This would be hard to maintain, because the content of the tests must be so dependent on the base version of the OS. * Write the tests in Python using libnfs-python. The tests could still be compiled as part of the base system, they just wouldn't work unless libnfs-python is installed from ports. But this is awkward because the tests are currently C++. So I would have to embed a Python interpreter into the C++ code. It would really obfuscate the test logic. * Store the tests in the base system, but detached from the build. Then create a port that builds them by mounting SRC_BASE, much like devel/py-libzfs does. It would then install them in /usr/local/tests. This is probably the least-bad option if I can't import libnfs into contrib/. What do you think? Is it acceptable to import libnfs intro contrib/? It's LGPL, except for a few headers that are BSD and some examples that are GPLv3. But we needn't use the examples, or even import them. https://github.com/sahlberg/libnfs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOtMX2gp46301jOA2OG8bqxDgxspqSYPafGNtxdvqyO-nk2Qtg>