This looks like a good incremental change, although I can't test it right now. But this program is also begging for some TLC. It could benefit from libxo output, and it's also a good candidate for a C++ conversion. The entire -w option seems like an avoidable hack, if output were printed more intelligently. Most ambitiously of all, this program is fairly begging for some kind of "xo_print_table" function, that would automatically size the columns. But your change is still a good one by itself.

In D47625#1085688, @imp wrote:

So read only ever returns one record

LGTM. If you're feeling ambitious you can add test cases for symlink destinations and the other command line options.

Shouldn't you delete cvt.pl? That looks like a one-time script to me.

At the 2024 FreeBSD Summit we took a poll. Not a single user thought it important to continue providing Pentium III-compatible prebuilt packages. So I'm going to commit this now.
{F102272979}

Looks good to me.

I agree. I can see a couple of other ways to fix this problem, but none are as easy as Mark's.

As Jan pointed out, this change will hurt the experience of PIII users. But it will improve the experience of P4+ users, and x86_64 users with 32-bit jails. So @emaste @jbeich , is that a good enough reason to commit it? Or do we need to canvas more people?

Thanks diizzy!

In D47227#1076997, @jbeich wrote:

This new option doesn't affect bootstrap.

lang/rust uses lang/rust-bootstrap instead of vendor binaries, so changes (like codegen) to the former affect the latter. Upstream has stopped providing anything but rust-std for i686-unknown-freebsd many years ago i.e., there's no vendor bootstrap for i386.

• Respond to @jbeich's comments regarding UPDATING

In D47227#1076964, @jbeich wrote:

But add an SSE2 option. Disabling it will allow the port to be used on Pentium 3 an doler CPUs.

Bootstrap uses SSE2, so the port won't build on such old systems. Converting to a flavor may help but lang/rust itself may remain unbuildable unless the bootstrap is flavorized or an existing installation can be used as bootstrap.

• add an UPDATING note

Fine by me. Thanks for proactively testing the fusefs test suite build.

The change LGTM. But the tests ran suspiciously fast. Are you sure that fusefs.ko is loaded?

In D46853#1068459, @olivier wrote:

New version using requiered_progs.
But anyway which port should insall all the missing sg_* binaries ? I don’t find instruction about them.
Because right now they are ignored:
https://ci.freebsd.org/job/FreeBSD-main-amd64-test/lastCompletedBuild/testReport/sys.cam.ctl/prevent/allow/

Technically, ctl can be used without iscsi, so I think that MK knob is named wrong. But that's beyond the scope of this PR. I think that this change is OK. Note that another way to fix the same problem would be add ctladm to the list of require.progs in each test case within that directory. But your method requires less code.

Note that some of these tests, including the CVE-2024-4241 regression test, depend on a recent unreleased change in sg3_utils. For now, you can only get it by building sg3_utils from its git source.

I don't know this area of code, but your changes LGTM. At least, I can't spot anything wrong with the locking or error handling.

This seems reasonable. Jenkins already disables the ZFS tests for normal runs.

Independently fixed by @markj in a58ece87303f882367105c92a27268ed6befa655

I'm still a little shaky on the details of virtio-fs, but I can't find anything obviously wrong here.

Can you add a man page, too?

This LGTM. And BTW, I successfully tested it with an out-of-tree libgeom consumer.

Note, this was reviewed by @fuz , who gave his approval over IRC, but was unable to login to Phabricator at the time.

The changes to tinyfuse.hh look good. Now I've reviewed mount_qemu_fwcfg, too.

This looks like a cool project. I've only reviewed tinyfuse.hh so far; I'll come back for the rest later. BTW, if you want to see an example of a fuse file system written in C++ that doesn't use libfuse, you could check tests/sys/fs/fusefs/mockfs.cc . It basically wraps googlemock.