In D53814#1233992, @quentin.thebault_defenso.fr wrote:

Added a unix: prefix for UNIX domain sockets

This enables the use of relative paths.
To avoid parsing the configuration value twice, I decided to pass a sa_family_t parameter to the rfb_init function. I hope that is an acceptable way to implement it.

Implementation looks fine to me, but I defer to bhyve-y folks for final review... in particular, I do wonder if they might prefer some more explicit prefix like unix:/path/to/sock

Just dropping a note that this leads to ~10x throughput to pkg.f.o on my laptop -- previously averaging somewhere around ~2-3mbit/s due to constant out-of-order acks, up to ~25-30 mbit/s on average

In D53750#1227230, @jlduran wrote:

I suggested via email:

diff
--- a/usr.bin/lam/lam.c
+++ b/usr.bin/lam/lam.c
@@ -213,11 +213,11 @@ gatherline(struct openfile *ip)
        *p = '\0';
        if (c == EOF) {
                ip->eof = 1;
+               if (ip->fp == stdin)
+                       fclose(stdin);
                if (ferror(ip->fp)) {
                        err(EX_IOERR, NULL);
                }
-               if (ip->fp == stdin)
-                       fclose(stdin);
                morefiles--;
                return (pad(ip));
        }

But this is fine as well. Plus, it has tests!

Hmm, the definition came in here:

-1 -> 0

Add missing size check to the startmethod _attach()

I know ray@ pops in sometimes so we might give him (and Ed) a little time to object, but I also didn't really see a reason to impose this particular limit. I did wonder if it was just an oversight because NSIG on other platforms *does* usually cover all valid signals (as far as I've observed)

Describe the switch a little more in HISTORY and update the STANDARDS; the
notable changes since -2004 are this different error return and clarification
of EFBIG to surface if the file size limit is exceeded (with generation of a
SIGXFSZ).

Do a read-once load of si_drv1, just in case. Amend the comment to try and
describe our solution more completely

Correct it for the file-specific unsupported mode as well

Fix observed test failures; there's only a few places that we expect EINVAL.

Simplify a bit using the net epoch

In D52740#1221574, @0mp wrote:

In D52740#1221525, @ziaee wrote:

(not a inetd-sme) I thought they were Nm because these utilities are part of inetd?

AFAIU, these utilities are just called by inetd and are not internal. I've not checked the code but my understanding is that inetd is able to run any service the user specifies in the config file.

Dance around tunmtx to protect against concurrent tun_destroy() / tunopen()

Already landed in a505b80b2f038409300cd05e2ea95822942404e2, and it's clear nobody is using it in a way that this is urgent to MFC independently

In D53350#1218507, @glebius wrote:

Can you please point me to how reproduce the problem? IMHO, we should just provide a KPI to register new sysevent_groups and pre-register them before the events.

Thanks!

Presumably tested, LGTM

Seems reasonable to me (from a flua perspective; I defer to bapt for nuageinit in general, of course)

Please be sure to include 0d4642a as Fixes metadata so that it's clear they need to go together both for MFCs and downstreams that might be consuming main.

Ahh, whoops- my bad!

We'll also need PACKAGE in libexec/flua/libfreebsd/Makefile.inc, but I think this covers everything else in main.

Whoops, good catch

In D52824#1213747, @des wrote:

@kevans did you get around to fixing the lua bootstrap issue?

Address review feedback; use stat -h and stop asserting on hole reporting