In D51371#1181088, @des wrote:

In D51371#1181080, @asomers wrote:

You don't need to create a thick jail. In fact, you don't need a separate jail file system at all. It's totally fine to create a jail anchored at / .

No, it is absolutely not fine. Both jails run daemons which create pidfiles and sockets in hardcoded locations.

In D51371#1173192, @des wrote:

I would be delighted if someone could suggest a better way to populate a thick(ish) jail than what I'm doing here, btw. The jails weigh in at around 200 MB each on amd64.

The commit message says "jail". But kern.vm_guest doesn't change in a jail. Did you mean to say "in a VM"?

You need to add "LIBADD= xo" to usr.bin/fstat/Makefile. Also, a lot of fields are missing in the html output, for example file_type. Is that intentional?

In D51316#1172010, @arrowd wrote:

Would you like me to check if the test really fails on an unpatched system?

The regression test is at D51316 .

I have tested this patch and confirm that it works. I've also written a minimal reproduction case, which I'll post as a separate review. And while I understand Mark's concern, I tend to agree with arrowd's approach. BMAP should be advisory, and readahead should be optional, so errors in neither should cause the main read to fail.
But I would like to see a better commit message. It should contain enough information to describe the problem without resorting to Bugzilla, since Bugzilla might not be around forever.

I have no idea why Arcanist decided to include all of those extra revisions when I updated the diff. I did not rebase. Only the most recent three revisions are intended to be part of the review. I'll abandon and reopen.

• Abandon the custom kernel module. Rely on existing syscalls instead.
• move the test into the kern directory

The fusefs part LGTM. I didn't read the rest.

In D51081#1165925, @olivier wrote:

In D51081#1165915, @asomers wrote:

This is ok. It should normally be unnecessary, though, because ctladm should always be installed. Are you using pkgbase or something? I guess it might be optional in a pkgbase world.

Yes, indeed, it should now always be installed. However, we have a custom world (WITHOUT_ISCSI) and kernel (no device ctl), and since ctladm is no longer gated behind WITHOUT_ISCSI (commit 08419bf19469), this is the cleanest way I’ve found to fix this specific use case.

This is ok. It should normally be unnecessary, though, because ctladm should always be installed. Are you using pkgbase or something? I guess it might be optional in a pkgbase world.

In D50826#1161127, @arrowd wrote:

LGTM, but you're still ORing POLLHUP into revents, not setting it. As I mentioned in comment, it seems that the FreeBSD way to report EOF is to return POLLHUP only.

In D50831#1161443, @kib wrote:

We did not finished with stabilizing the kernel interface yet, and not much started looking at the proper userspace facilities. It might end up built-in into err()/warn() so uexterr_gettext() would be left as some internal function. I simply did not considered that we are there yet.

For the exterrctl(2), the man page would be eventually added, but with the warning similar to that for thr*(2) and sigfastblock(2) that the interface is for C runtime and should not be used by the app code.

In D50831#1161438, @arrowd wrote:

What man page? The information on how to read exterrors is located in kdumps manpage.

This change is ok with me. But I would still like to see a man page and some usage examples from userland.

This is an interesting new feature. But how do we use it? There aren't any examples yet, or any man page. We could easily add test cases for the mount and kqueue errors to the fusefs test suite.

• fixup: output POLLHUP regardless of the contents of events

In D50799#1159803, @arrowd wrote:

LGTM, but my review doesn't worth much.

• Respond to gleb's comments

A redeclaration of an entity without a linkage specification inherits the language linkage of the entity and its type (if exists).

A few functions, like conf_set_debug, will now be extern "C" in the header file, but not in their implementation. It might work, but I don't think it's right. Also, conf.c seems to have two purposes. It defines C functions used by parse.y, and it also defines C functions used by ctld.cc. Maybe we should leave conf.c as a C file, but move some its ctld functions into ctld.cc itself? OTOH, if you're going for "minimal set of changes necessary to build as C++, it would be easier just to move those prototypes out of the "extern C" section.

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.