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

In D28952#648255, @jamie wrote:

Might PRIV_SCHED_CPUSET be sufficient for this? If a process has the ability to explicitly expand the current cpu list, it makes sense for it to be able to implicitly do so when attaching to a jail.

first pass at a review

unfucked this differential, after accidentally updating with the wrong diff

address @kevans' feedback, by moving local_rc *.pkgsave skipping into the skipping of scratch files, since that issues a warning.

address @kevans' feedback.

suggestion to improve warning

yes, please

is there an equivalent std.debug file for stable branches?

address @0mp's comments.

addressed @swills' concerns.

aah, very good

fix @emaste's formatting remarks from IRC

i'm getting this message on boot / shutdown:

same functionality, written in C instead of python style C. thanks to RhodiumToad:

In D27959#624597, @emaste wrote:

alternatively, we could say: if it has >= 2 '.', skip it

Yes I think that's reasonable if you're up for updating this review with that change (or I'll take this one as is).

In D27959#624564, @emaste wrote:

LGTM even though we're probably close to the point where it makes sense to have a loop with a list of extensions to ignore.

this almost works 😬

this change makes my build world (in poudriere) fail

address @yuripv's comments.