FWIW our tree already has some tests that require C++-11. See lib/libc/tests/stdlib/Makefile. So importing an old version of googletest may not be worthwhile if it means forfeiting important features. Also, you may not have noticed, but there's already one googletest program in base, in cddl/usr.sbin/zfsd/tests. It's been there for years, but never hooked up to the build.

Sorry for the duplicate revision. I'm having curl problems.

This review is enormous. Might I suggest that you cancel it, and then create two smaller reviews? The first would cover adding openrc to contrib, and the second would cover everything else.

I haven't read all 1710 lines of netmap code, but here are a few basic ATF questions. The test looks like it requires root. If so, the Makefile should have TEST_METADATA+=required_user="root". Secondly, would anything bad happen if two of these processes were running simultaneously? If so, then the Makefile should have TEST_METADATA+=is_exclusive=true.

LGTM. Do you you need someone to commit this for you?

Clarify why write(2) updates st_ctim

Use kib's preferred wording for directory-updating syscalls.

Also, for ordinary file accesses, the page fails to mention modifications of the writeable memory mappings of the files.

Leave syscall list open-ended.

Also note that mknod does not update atime

In D18410#391986, @kib wrote:

I do not understand this change. Are you claiming that link(2) modifies mtim ? If yes, for which vnode ?

In D14567#383658, @oshogbo wrote:

@cem, @kib, @emaste, @jilles I would like to commit it as-it-is but pjd suggested to change the name to funlinkat? After some thoughts I also think that funlinkat is a bether name 'fd' suggests that it's working on 'FILE *'. Do you agree?

Handle allow.mount.nofusefs too

Of course, stupid me. But I'm having trouble testing it. What's the proper way to pass the "nofuse" option on the jail(8) command line? Neither allow.mount.nofusefs nor allow.mount.nofusefs=1 work.

Wow, nice contribution! But a few things need to be fixed:

1. When we import foreign code, if there's any possibility at all that we might sync it again in the future, then we import it to the vendor directory before merging it to the contrib directory. See contrib/netbsd-tests for an example.
2. Other concerns inline.
3. I haven't fully reviewed the Python code. I'll do that after you fix the sh and make problems.
4. Any files that come from OpenBSD should be committed verbatim to the vendor directory, then copied to the contrib directory. Then they can be modified in contrib.

Oops, looks like this one's my fault. Thanks for fixing it, Mark!

In D17110#364972, @markj wrote:

In D17110#364950, @markj wrote:

In D17110#364949, @asomers wrote:

Do the tests still pass for you? After your latest change, I get the "connection wasn't accepted" error every time.

Yes, I just noticed that. (I rebuilt and ran the tests on two different machines by accident.) It seems like the polling loop is needed after all, which is somewhat surprising to me given that we're using a blocking connect().

I guess this is expected behaviour for TCP. connect(2) returns once the SYN|ACK reply is received, but the child socket isn't complete until the final ACK is received, so there's a window that we have to account for.

Do the tests still pass for you? After your latest change, I get the "connection wasn't accepted" error every time.

In D17115#364879, @vangyzen wrote:

In D17115#364864, @asomers wrote:

Two annoying questions:

1. The Wayback machine shows me that IANA sometimes removes a port assignment. Sadly, I haven't been able to find any official historical information. What will FreeBSD's policy regarding removing assignments be?

I doubt there has ever been such a policy. By default, we will remove it on the next update. I think this de facto policy will be sufficient. Administrators who need to keep the assignment can simply add it to this file on their systems.

All good here.

Two annoying questions:

In fact, you don't even need the second process for this test. It's possible to do this entirely with one single-threaded process. See the "accept_success" test in tests/sys/audit/network.c for an example. Basically it goes like this:

for (i=0; i<sdcnt; i++)
    listen(server_fd[i]);
while (true) {
    client_fd = socket();
    client_fd.connect(server_addr);  //blocking, but returns immediately
    for ((i=0; i<sdcnt; i++) {
        if (accept(server_fd[i]) == 0) {    // non-blocking
            acceptcnt[i]++;
            break;
        }
    }
}

What do you think of the single-threaded approach?