Just some minor simplifications, I think we can just use tun_fd being a valid fd as an indicator that we should be tunneling instead of tracking that in separate state.

Frankly, I'm not comfortable with taking -this- much of a diff without looping in upstream in advance -- the SEE ALSO proposal was reasonable, though. Adding Jason in on this.

Address new comments, drop in some XXX notes for future work

Remove the devdesc arg to dv_open() entirely. f->f_devdata is always a devdesc
for the initial open(), modulo one instance in userboot that calls dv_open()
manually. Adopt it to the new interface like we do in uboot and just fake a
properly constructed struct open_file to pass in.

Sigh, typo in the commit message: both result in ARCH=ppc64, as they did before. (not ppc)

Bah, sorry, I suck. Manually related the commits in after committing it just a bit ago; closing.

One final update; re-scope wg import down to both src/ and .gitignore a bunch of files that we don't need (many with GPL-2-only, just to avoid false-positives of folks scanning the tree and wondering if we use those)

Toss in a barrier prior to wakeup; perhaps paranoid, but it seems like a
reasonable concern

Yup, LGTM!

Empty -p flag should be treated the same as an omitted --tmpdir to actually be
compatible; fixed this omission, updated the manpage appropriately and added
a test for that specific scenario.

In D37121#843439, @wosch wrote:

In D37121#843438, @kevans wrote:

In D37121#843436, @wosch wrote:

I tried to compile the new feature. But the patch failed. Is the patch up-to-date for -current?

I was previously synced to rGed5e7fb16c by mistake, but I rebased this branch to rG866beaa0aa9 and it still builds OK here -- what does the failure look like?

curl -L -o diff 'https://reviews.freebsd.org/D37121?download=true'

% Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                               Dload  Upload   Total   Spent    Left  Speed
0     0    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0

100 8388 0 8388 0 0 13312 0 --:--:-- --:--:-- --:--:-- 721k
wosch@cloud2.dev <06:08:21> 14.0-CURRENT [~/projects/src] 508
bash$ patch -p1 < diff
Hmm... Looks like a unified diff to me...

The text leading up to this was:

diff --git a/etc/mtree/BSD.tests.dist b/etc/mtree/BSD.tests.dist

--- a/etc/mtree/BSD.tests.dist

+++ b/etc/mtree/BSD.tests.dist

---

Patching file etc/mtree/BSD.tests.dist using Plan A...
Hunk #1 succeeded at 1060 (offset 2 lines).
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/Makefile b/usr.bin/mktemp/Makefile

--- a/usr.bin/mktemp/Makefile

+++ b/usr.bin/mktemp/Makefile

---

Patching file usr.bin/mktemp/Makefile using Plan A...
Hunk #1 succeeded at 1.
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/mktemp.1 b/usr.bin/mktemp/mktemp.1

--- a/usr.bin/mktemp/mktemp.1

+++ b/usr.bin/mktemp/mktemp.1

---

Patching file usr.bin/mktemp/mktemp.1 using Plan A...
Hunk #1 succeeded at 37.
Hunk #2 succeeded at 93.
Hunk #3 failed at 146.
1 out of 3 hunks failed--saving rejects to usr.bin/mktemp/mktemp.1.rej
Hmm... The next patch looks like a unified diff to me...

The text leading up to this was:

diff --git a/usr.bin/mktemp/mktemp.c b/usr.bin/mktemp/mktemp.c

--- a/usr.bin/mktemp/mktemp.c

+++ b/usr.bin/mktemp/mktemp.c

---

Patching file usr.bin/mktemp/mktemp.c using Plan A...
Hunk #1 succeeded at 38 with fuzz 2 (offset -1 lines).
Hunk #2 failed at 53.
Hunk #3 failed at 63.
Hunk #4 succeeded at 103 (offset -7 lines).
Hunk #5 succeeded at 145 (offset -1 lines).
Hunk #6 succeeded at 183 (offset -7 lines).
2 out of 6 hunks failed--saving rejects to usr.bin/mktemp/mktemp.c.rej

In D37121#843436, @wosch wrote:

I tried to compile the new feature. But the patch failed. Is the patch up-to-date for -current?

With rG866beaa0aa95 this has successfully booted a Raspberry Pi 4 both with our armstub8* that does PSCI and with the upstream stock armstub8*, and we use this actively on M1 WIP as well.

In D32936#841641, @allanjude wrote:

The reason we stopped doing this originally, is that if ZFS imports the pool using disk names like /dev/ada0p3, then the GPT label version like /dev/gpt/swap went away, and then you ended up with no swap mounted.
I don't know if things have changed somewhat since when I ran into these problems around 2015. I know there was some work to try to mitigate the issue.

Clean up the diff a bit more; don't rename bfr -> buf for split1(), but maintain
the MAXBSIZE -> sizeof(bfr) change.

Switch to getline() for split2's buffer management, move the global buf/bufsize
into split1() and keep that at MAXBSIZE.