I think it might be a good idea to add the docs group as reviewers for this.

Feel free to commit at your leisure then - since I still don't have svn access, just project membership (that I need to get setup).

If the VM high watermark levels are tweaked, OOM from ZFS on swap can be entirely avoided. Don't know if this is relevant?

The description of what it does makes sense, although I can't spot if that's actually what the code does.
Otherwise, LGTM.

I think you need to actually add them as reviewers?

The feedback I provided on the git repo has been fixed, so I'm more than happy with this change. I don't have permission to accept nor commit it, though.

I can't help with the review itself, but the least I can do for this excellent idea is to remind you that you'll want to add some reviewers so that your code can be reviewed. :)

Since this review touches more than the man-page, you may want to talk to a few commiters about getting it reviewed by them. The easiest way to find people is to look at who touched these files last (ie. via svn/git blame). :)

Since it's accepted, would it be possible for this diff to go into HEAD?

Is it okay to ask what the status of this is? Because it looks really useful!

I can't help you with a review, but I can certainly remind you that you should probably get some reviewers involved. :)

I can't review for you, but I think it would be smart if you got some individual reviewers attached instead of just the whole group?
It's a good idea though. :)

I'm not a commiter, but since this looks like a neat thing to have, may I suggest you get some reviewers added?
One way to find reviewers is to look through the code for who touched these bits (MFU/MRU-like) and then ask them if they want to review it, or send an email to the appropriate mailing list asking for reviewers.

Out of interest, who's taking care of the commit?

I hope this review isn't waiting on my feedback, since I just had a question that was answered. I can't actually review the code.

This might be a dumb question, but does the process title change often enough that setproctitle_fast() added in rS335939 should be used?

Found two things which may need some TLC.

Noticed only one thing, otherwise it looks good to me.

Looks good to me.

Looks Good To Me!

I had to double-check i.e vs. eg., and found that it scans, so it looks good to me.

Supply a patch that (should) work.

Turns out this revision didn't work, will update with a new diff that fixes it once I get the OK for the change.

They do, thank you. :)
Nom.

Applied the changes from rene@ after satisfying myself I understand why they were made.

Added entities properly, sorted alphabetically

Added forward slash on last variablelist tag.

I'm really not sure what I'm supposed to do about these entries (nor am I even sure where to add them), because upstream (linux drm/kms stack) doesn't seem to provide these man-pages and I'm not at all capable of writing them.

Looks Good To Me!

Corrected which drivers work for what cards.

Added amdgpu, and explain that radeonkms and amdgpu are in general used for older and newer graphcs respectively.

Added missing semicolon.

Fixed issues pointed out by bcr@

Remove exteneous article.

Avoid weasel words, in accordance with the documentation primer.

For posterity's sake, the context of this review is a conversation on Twitter regarding the state of xattr/EA in FreeBSD for ZFS, with a special eye to multi-labels.

Did you think about getting some reviewers attached for this, as well as fixing the various errors?
The reason I ask is because it doesn't seem like a bad change, but if it's going to go into the tree there's typically some sort of review process.

I shan't comment on it on the change itself, but have you considered getting some reviewers attached to this?
Changes to FreeBSD typically don't land automatically, and there usually has to be at least some sort of review process.