From nobody Fri Dec 31 21:21:19 2021 X-Original-To: freebsd-arch@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 84586192351B for ; Fri, 31 Dec 2021 21:21:37 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ot1-f51.google.com (mail-ot1-f51.google.com [209.85.210.51]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JQdPD5tY8z4YJD for ; Fri, 31 Dec 2021 21:21:36 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-ot1-f51.google.com with SMTP id i5-20020a05683033e500b0057a369ac614so36698188otu.10 for ; Fri, 31 Dec 2021 13:21:36 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=6DrH5Njm/zsdRrvo56bcqr/IbA/Jh8RQhy6imeXPDjY=; b=uIkJfHxmmQ+MbPMtUruDc1wHLazyPQiGWZUH8zTyic2oPqs9O+S0raiRtp9PnpX5dl +zJnOW4CXOOI+phll+fz5HUh6EapIL51N41z886D3XTThwb0GBgvjaT55ZG+XJpgFxA3 UpXCBLJAgc1iFyXXs8Yrtu2Y+lqp0YemAW9LnaCKuUOE1vStfjvrTkC8gvu1mVrf4JeH n+SJkTWfHan336a29nu8JR7dKLwTywuf5Mw7fO4Bqld68DYo2PHHqdtgUb89wBrpld/g Yoy5MZv3uULIo8QMxbxvWY/cHYxNMYOwlZst3GSRqMT8cxPpGeLQzV8aEF6uULG3jb7Y SoeQ== X-Gm-Message-State: AOAM533AtIbYeBXo07fqKwIGvR8pHWxrcAz2teCjOFXkObw2Z5KzYTi/ yYBbEllPtB2QYF31uudSIyr1ku+xw1JCrQEkWowp7E9humg= X-Google-Smtp-Source: ABdhPJxkOFZbr2fQQiqvAVFGdQMlTmMFKZyY0OWdM6YhQKw2nRrm8crztUxPYQNJtidI0UVdk4U1uPHFd0ubI+ZALQQ= X-Received: by 2002:a9d:554f:: with SMTP id h15mr26908152oti.111.1640985690158; Fri, 31 Dec 2021 13:21:30 -0800 (PST) List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 From: Alan Somers Date: Fri, 31 Dec 2021 14:21:19 -0700 Message-ID: Subject: LGPL code in /usr/tests? To: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4JQdPD5tY8z4YJD X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of asomers@gmail.com designates 209.85.210.51 as permitted sender) smtp.mailfrom=asomers@gmail.com X-Spamd-Result: default: False [2.00 / 15.00]; TO_DOM_EQ_FROM_DOM(0.00)[]; FREEMAIL_ENVFROM(0.00)[gmail.com]; FREEFALL_USER(0.00)[asomers]; FROM_HAS_DN(0.00)[]; RWL_MAILSPIKE_GOOD(0.00)[209.85.210.51:from]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_DN_NONE(0.00)[]; NEURAL_SPAM_MEDIUM(1.00)[1.000]; RCPT_COUNT_ONE(0.00)[1]; ARC_NA(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(1.00)[1.000]; DMARC_NA(0.00)[freebsd.org]; RCVD_IN_DNSWL_NONE(0.00)[209.85.210.51:from]; FORGED_SENDER(0.30)[asomers@freebsd.org,asomers@gmail.com]; SUBJECT_ENDS_QUESTION(1.00)[]; R_DKIM_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[asomers@freebsd.org,asomers@gmail.com]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-ThisMailContainsUnwantedMimeParts: N 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