Even though we relocate this binary, this value is invariant. And less than 32 bits, though that shouldn't matter here

It was a good trial of the idea against the whole FreeBSD Test Suite with promising results. The discussion of the Kyua jail support patch (https://reviews.freebsd.org/D42350) ended up with opt-in approach. Thus, marking this as closed.

Have you considered implementing Apple's copyfile API?

• Introduce dedicated vnode_disk_create_vobject() for use by g_vfs_open(), so we don't have to do vn_isdisk() checks for regular files.

@glebius I ran into this while running the kern tests. This new test is failing reliably for me, and it looks like in CI too, e.g. this run on April 9:
https://ci.freebsd.org/job/FreeBSD-main-amd64-test/25066/testReport/sys.kern/unix_seqpacket_test/random_eor_and_waitall/

In D45253#1032342, @lstewart wrote:

Nit: why require tfb_tcp_handoff_ok() be implemented by a stack rather than treat the absence of the hook's implementation to be an implicit ok? Many of the hook functions are optional so it seems a bit unexpected to require that this hook function be implemented.

Some functions are mandatory, some are optional. So I think it just needs to be clear what this function is.

Make changes to address feedback.

I accepted the review, I said that I do not have rational arguments against it.

Nit: why require tfb_tcp_handoff_ok() be implemented by a stack rather than treat the absence of the hook's implementation to be an implicit ok? Many of the hook functions are optional so it seems a bit unexpected to require that this hook function be implemented.