Would it be an idea to refer to this manual page from boot(9), boot(8), and/or some other relevant manual pages - to make it easier to discover?

LGTM. :)

This landed with commit bd6dce978c1a, but I forgot to add the differential revision tag.

I think it'd be nice to get all other functions marked up properly too, unless they're part of display blocks (Bd Ed macros in mdoc).

Address feedback by PauAmma

The proper way to solve this would be to use /usr/bin/env $BINARY because if that doesn't work, the OS that the tree is being built on isn't POSIX-compliant at all.

This looks good to me.

There's only one minor nit, but otherwise it looks good to me.

Are there other places where -(j|J) -1 is used to list all jails, instead of simply doing -(j|J)?

Also, to channel bcr:
Remember to bump .Dd :)

Try to address feedback by a.wolk

I don't think enough context was included, because I'm still seeing "Context not available" - any chance you can use arcanist from ports/packages (as described on the wiki article I linked earlier) or src/tools/tools/git/git-arc.sh (which can be installed by doing make -C /usr/src/tools/tools/git/ install (which requires arcanist, git, and textproc/jq?

Could you please update the diff to one made using the instructions on the Phabricator wiki article?

This is only true if you use format-patch?

I believe you need to use git-am(1) to get the metadata (author, timestamps, et cetera) applied.

Here's a few things I noticed.

For the record, the mdoc looks good to me now.
I can't speak to the code.

In D32269#728549, @rew wrote:

Which item macros are you referring to?

Did the item macros disappear by choice? Just checking.

Just a minor nit, otherwise it looks good to me.

I noticed that there are several places where a phrase is entirely or almost entirely repeated, and in my experience that's the sort of thing that makes it hard to scan through a manual page quickly - so I think it might be a good idea to rephrase things a bit.
Ideally I'd also really like to see the words include and exclude be used, as they're the kind of keywords that one would look for when dealing with this kind of thing.

LGTM. :)

I've given it another once-over, and am pretty happy with it, so unless anyone else has any interjections, I say it's good to go.

In D31707#715576, @bcr wrote:

That's right. My understanding is that everything is a dataset unless it was created by "zfs create -V ...", which for me is a volume (and used in this way). As you said, it may change or even blur some more with future changes. My idea is to use them consistently, for example mention datasets everywhere when it comes to ZFS features. When involving mountpoints, I'd refer to file systems, like this: "Mount the dataset as a file system into the directory tree." That way, we use it only when necessary, but keep the dataset syntax. Same when it involves volumes.

In D31707#715576, @bcr wrote:

Maybe one more reason to use dataset more to avoid this ambiguity? ;-)

These are a few things I spotted, but I'm not sure I caught everything and I'm on the wrong side of entirely sober. :)

Can you switch this diff to one with context? It makes it easier to make suggestions. :)

Just some minor nits.

I clearly shouldn't review things when I'm tired. Sorry. :(

Seems like an excellent idea.

I don't really have time for this right now, so someone else can go ahead and commit it once it's been accepted.

In D30589#687207, @imp wrote:

I don't like the passive voice, due to forced conditioning in high school Freshman English.... however, I know that's the style here...

The documentation team prefers to avoid use of 'you' in the handbook (and any other documentation).

Have you tested with textproc/igor and mandoc -T lint?

In D30336#681311, @a.wolk_fudosecurity.com wrote:

Updated the raw diff using the git show -U999999 <commit-hash> > change.diff method. Hope that helps! :)

Address feedback by 0mp

The current diff you've uploaded lacks context for Phabricator to tell which part of the file it applies to (I don't know why Phabricator can't always figure out the context), which is why the "Context not available" message appears.

Yes, it would be good to have a documented method of checking the protected flag, so go ahead and add that.

Fix cross reference

Address feedback by ceri

In D30330#681159, @ceri wrote:

One last nit, sorry - could you sort these alphabetically, with _limits and _login_class above _nice and _oomprotect after it?

Address feedback by ceri and Adam Wolk

In D30330#681137, @a.wolk_fudosecurity.com wrote:

I found out the hard way, that an rc script overriding start_cmd ignores some mechanisms. This may be by design. Those ignored are at the least:

• _oomprotect
• _user
• _limits
• _fib
• _chdir
• _nice

Unfortunately, some ports like PostgreSQL redefine start_cmd which would make _oomprotect="ALL" silently not work for the database. I am not sure where it would be a good place, but I think it would be worthwhile to document that redefining ${name}_cmd has such a pitfall.

Looks good to me, let's get this commited.

I think it would be better to check for the individual component parts, as @ygy suggests, and if any of them aren't found, recommend installing ports/textproc/docproj - but only print the error message once, even if multiple dependencies aren't found.

[source,shell] would indicate that a particular section using monospaced blocked text is a shell script.

@dbaio Since it has been approved by a ports commiter (you), doceng (bcr), and a doc commiter (me), can I go ahead and commit this to the ports tree, or do you want to?

I will note that PDF is mentioned as an optional part in the FDP quickstart, but I don't think it's going worth holding up the review over this.

Yes please!

Adding a bunch of spaces doesn't need much approval, but have some anyway. :)

Only one tiny nit left, then you can go ahead and commit it with Approved by: debdrup

Looks good to me now, go ahead and commit with Approved by: debdrup

Looks good to me. :)

In D28609#658423, @driesm.michiels_gmail.com wrote:

I don't understand why the legacy docs are still there. They are not kept up to date as far as I can tell.

Looks good to me.

The patch doesn't apply cleanly for me, and it doesn't look like a trivial fix.

The only thing I'd note is that [source,bash] should be [source,shell].