In D38898#885682, @jmg wrote:

I didn't see any in your config listed at: https://gist.github.com/igalic/dba54db678ad2f12b08d35504e7909de#file-qemu-conf-L87 which is why I assumed there wasn't one, but maybe a -nic on the command line automatically adds a network adapter. (I'm a qemu newbie, so I didn't even know a config file could be created till you posted yours.)

For my system, I'm using the command:

qemu-system-aarch64 -cpu host -accel hvf -smp 2 -m 4096 -drive file=pflash0.slow.img,format=raw,if=pflash,readonly=on -drive file=pflash1.slow.img,format=raw,if=pflash -M virt -device virtio-gpu-pci -display default,show-cursor=on -device qemu-xhci -device usb-kbd -device usb-tablet -monitor unix:qemu-monitor-socket,server,nowait -device intel-hda -device hda-duplex -device virtio-rng-pci -drive file=vm.raw,format=raw,if=virtio,cache=writethrough -nographic -serial mon:stdio

In D38898#885654, @jmg wrote:

So, I think what might be wrong is that you don't have another virtio driver to "unstick" the virtio queue. FreeBSD only has drivers for balloon, block, console, network, entropy and scsi. I looked at your config, and the only other device you define that is supported by FreeBSD is balloon. In my config, I'm using both network and block so it's possible that it's working here only because there is additional disk/network traffic causing the rng events to get dequeued...

rebuilt with this patch, here's the disas:

now also at https://github.com/freebsd/freebsd-src/pull/670

closing this based on @mjg's feedback.
I'm going to have to rethink this completely.

it's been a while. update this to bug people

Given the fixes the go toolchain has received, this blanket fix should no longer be necessary

address @imp's feedback.

one day, i will use arc and it will not mess up my review.
one day, really soon.

address @pauamma's feedback.

In D27959#880578, @pauamma wrote:

You didn't ask for manpages approval. Is that deliberate?

add documentation

I'll be updating this review and try to revive it.

I'm going to update this review with an edit to the man page, and then we can revive it.

we don't actually seem to have an irdma(4) man page: https://man.freebsd.org/cgi/man.cgi?query=irdma&sektion=4&manpath=FreeBSD+14.0-CURRENT

we don't actually seem to have an if_plip(4) man page

we don't actually seem to have a sbni(4) man page.

we don't actually seem to have a smc(4) man page

we don't actually seem to have an al_eth(4) man page

we don't actually seem to have a ic(4) man page

In D38382#872773, @mhorne wrote:

These are great guidelines.

As a related, but tangential improvement, I would suggest creating a small PR template in the src repo that points to this page/section. This makes it more discoverable. Having the guidelines linked/listed when creating a new PR allows us to more easily justify immediate rejection of PRs that don't follow them ("you didn't read the instructions").

https://docs.github.com/en/communities/using-templates-to-encourage-useful-issues-and-pull-requests/creating-a-pull-request-template-for-your-repository

how about --help?

after feedback from @kevans on IRC, I'm abandoning this revision, because it's the wrong way to solve this problem:

• fix case syntax
• use dirname, not basename

we don't actually seem to have a man page for this driver

we don't actually seem to have a man page for this driver

we don't actually seem to have a man page for this driver

In D38294#870088, @mjg wrote:

which entries don't qualify?

i'm saying this creates potential for something to be broken and start silently failing

?

In D37189#845161, @manu wrote:

In D37189#845155, @emaste wrote:

the growfs script handles ZFS as well

Ah right, didn't knew that.
Let's close this one then.

I've really just looked properly at the man page, since i don't know the code, so that's what my comments are about.

some questions and recommendations

this says MFC 1 week. that was two weeks ago.
This revision links to machine-id(5) on Linux, but perhaps we should have that man page ourselves

with my cloud-init contributor hat on: I like the basic idea of this, because it can live in base.
The big caveat is that this only provides, probably: can only provide, the most basic functionality seen here.
Everything that cloud-init handles in modules, might end up being too much work to keep up with upstream.

address @pauamma_gundo.com's comments

address pauamma's comments

In D34563#784083, @markj wrote:

Seems reasonable. I think /dev/log is legacy anyway.

modify net/syncthing build to build the binaries as pie

is this going to be MFCed?

how will this behave on pkg upgrade?

perhaps an entry in release/packages/Makefile.package
could be useful

i wonder if this regression is the cause of https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254173

add comment for prison_allow()

address review comments

address @jamie's and my own review comments

address @kp's review comment.

address reviewers comments

In D29659#665036, @jamie wrote:

Yeah, I'd been meaning to get around to that ;-).

a bit late to the party, but

rebase

addressed in latest update

address @manu's review

fix spelling error

🙋🏻‍♀️

this looks sensible and good to me!

done

Apply @debdrup's suggestions