This LGTM. C++20 would be nicer, because it would simplify one thing in the fusefs tests, but that would require a whole new tinderbox run.

LGTM. Except that the commit message contains a typo: "uprivileged_user" => "unprivileged_user"

What maintenance burden, @kp? I think it's a worthwhile change. I've run into similar problems myself. I find it easy to have a system where something pulls in, say, lang/python311 but not lang/python3.

Ahh, sorry for the noise.

The old code certainly looks broken. I guess nobody was using it?

It's frustrating that file parsing is so difficult in C.

Yikes. I guess nobody was using those.

Did you check for any similar resource leaks in uclparse.c ?

Thanks for doing all this cleanup.

In D48798#1115132, @jhb wrote:

FYI, one hiccup with this plan is that yacc only generates C code. I am working on creating a dedicated C API to sit between parse.y and ctld.c so that the rest of ctld can be C++. Blech.

In D48798#1114872, @jhb wrote:

I'm somewhat torn on doing a big change while the nvme stuff is in flight, but I do think maybe we should just bite the bullet. git can handle renames pretty sanely for rebasing I think.

So what I think I would like to do is go ahead and convert ctld(8) to C++. The first commit would be to just rename all the .c files to .cc and change the Makefile, but make no other functional changes. We might need to a prep commit to add BEGIN_DECLS and END_DECLS to libiscsiutil.h. After that lands, you could rebase this and use C++ enum classes for these. I might also use classes instead of my protocol_ops structure in the nvme vs iscsi changes. It might be nice to use classes for several of the data structures in fact including auth_groups, portal_groups, etc. Also while updating certain things it might nice to use STL containers in place of queue macros, but that can be done incrementally.

Thank you!

The only improvement I could suggest would be to factor out the guts of both functions into a third, private function. That would save callers of nvmf_nqn_valid_strict from calling strlen twice. But it's probably premature optimization.

I think this is ok. Losing the ability to apply configuration once before daemonizing is unfortunate but understandable. If it's a problem, we can fix it later by using rfork. I also see that you're only passing a single-element eventlist to kevent, which isn't the most efficient. But ctld isn't supposed to get a high rate of connections, so that's fine.

• fixup: add eventfd too

In D48650#1109739, @markj wrote:

This change addresses the failing test, but there's a new failure in sys/netinet/fibs_test:same_ip_multiple_ifaces_fib0. The test creates two interfaces, then assigns the same IP address to each, with different masks. With this change, the second address assignment fails with EEXIST.

I'm not sure if that's actually a valid thing to do in practice; see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=189089 . Maybe @asomers remembers?

I guess this is OK, but I haven't ever done anything with the discovery code, so I don't know how it's supposed to work.

This LGTM. But now libiscsiutil is just begging for some ATF tests.

This is a great use of vnet.

• Cleanup trailing whitespace

In D48452#1105595, @olce wrote:

Out of curiosity, what's the need behind exposing this info? FYI, it seems va_filerev has been correct on UFS, ZFS and p9fs only, and filesystems using init_va_filerev() seem to set it to a dubious value.

In D48452#1105406, @rmacklem wrote:

In D48452#1105397, @asomers wrote:

Since st_filerev provides similar information to st_gen, should it also be guarded by PRIV_VFS_GENERATION in vop_stat_helper_post? And does it warrant mention in stat.2 ?

I do not know why st_gen is considered privileged information, but it might have
been that knowing it is useful when trying to fake a file handle?
st__filerev is not useful that way. It is really about the same as mtime and ctime, I think?

Since st_filerev provides similar information to st_gen, should it also be guarded by PRIV_VFS_GENERATION in vop_stat_helper_post? And does it warrant mention in stat.2 ?

fusefs currently doesn't set va_filerev at all. I can fix that. But with fuse, ctime updates can come from either the kernel or the server. So the easiest solution would probably be to make va_filerev be a function of ctime. Would that work with the Linux client, assuming we set NFS4_CHANGE_TYPE_IS_TIME_METADATA ?

This LGTM. Too bad Coverity can't figure it out for itself.

I think this is OK. But it would also be fine just to put an assert(j < max_queue_per_proc before the array dereference.

libtirpc did something similar: https://github.com/alisw/libtirpc/commit/1e786fc401ff625fdcec3e0bdc495125feb0a070 . NetBSD and OpenBSD still contain the lseek.

Does this option cause the port to build both the aarch64 and x86_64 freestanding targets, regardless of the host architecture? Why not build freestanding targets only for the host arch?

In D48198#1099255, @rmacklem wrote:

Exports, mountd and nfsd can be done in a vnet jail, if that would help?

In D48198#1099253, @rmacklem wrote:

I'm not sure I would have called the nfsd "odd". It is one of two
consumers of the VFS/VOP interface (I suppose you might call
the stacked file systems consumers as well?).

Being one of the two, it is definitely different than the local syscall
interface.

But, anyhow, it is definitely different than the local syscall interface
and not just not using VOP_OPEN/VOP_CLOSE. It uses VOP_LOOKUP,
but in a different way than the local syscalls, particularly w.r.t. name caching,
as another example.

@rmacklem do you think this does a decent job of approximating the peculiarities of nfsd?