Actually, everything seems reasonable. I just have one suggestion to try to make this functionality more obvious?

Ok team, what do you want me to do? We can keep iterating on this (although this is the extent of my understanding) or I can merge this.

This is really wonderful Minsoo, thank you so much for doing this.

That's all from manpages mechanical side of things. But I do not really know about syscalls to review the content.

I'm beginning to think all these Li's in the manpage are actually Fa "Function argument or parameter".

Can you also update release(7) with the new knobs?

Oh one more thing,

In D60002#1376597, @mchoo wrote:

Remove kern.sched.preemption (This is shared between 4BSD and ULE, so it should be in scheduler.4)

Dropped in favor of D59938

OK thanks @glebius!

Thank you!

The link in the test plan seems out of date?

(I may not be following, please excuse me if my assessment is incorrect)
Please stop this.
If you don't know what is going on in the patch, and cannot explain it, and use many words, also the patch is large, it is not useful and hurts.

What happened to the docs?

There is no spite or resentment behind my frustrated comment, please do not read into it too deeply. I did take it personally, but I do not agree there was anything escalatory about communicating that, especially after being directly asked what I think. I did not insult anyone, because I do not have any insults to issue. My statement was just, direct. It does make my life harder, and I asked please do not do this. My concern with the doc, as you know from doing release notes, is not that it will take more time later, it is that it will never get done. If it is done on time, it takes everyone an extra 10 minutes. If it is done later, it takes many man hours, starting with a frustrated user report (and who knows how many frustrated users did not bother to file the bug first), many hours of work to figure out what is missing, and so on. Archaeological docs is also the most unglamorous work that could never feed a family, and the damage to our reputation is done when things slip through the cracks and users find them. Similarly with release notes. We can not manually read through the commit log and parse everything that has happened to write release notes, and AI is not at that stage either. If the commit is marked appropriately we can do an acceptable job with only a few hours of work. If not, it takes days, which may or may not happen depending on availability of our teammates.

In D59425#1371655, @dteske wrote:

I'm thinking of moving these to tools/ or tools/tools/ as I'm not sure it brings much value to have them available in usr.bin/ -- absent any feedback on that, I'll just forge ahead to usr.bin/ as planned. Just spit-balling an idea that popped into my head.

Since it doesn't do anything, it is not necessary to remove them. However, since it doesn't do anything, it is kinda nice to remove them. To clarify, I was not asking you to remove them, I was just asking where you got the idea to do this because I have never seen anyone do this. Usually weird undocumented stuff comes from copying other files, so that's what I was wondering.

Thanks for doing this!

Thanks!

Please write something in src/RELNOTES. You can use Relnotes: yes commit message trailer in the future to automate this a bit. In general, please please do this anytime you add a new thing. Otherwise writing relnotes is an act of heroism.

In D59738#1370981, @obiwac wrote:

Also, you have your license format all mixed up :P

how so?

okay, sounds good!

what about without the "v8" since it's in the name?
i'm looking at this [0] and it seems to call it "Arm Cryptographic Extension" more often than not.

LGTM from manpages, please Relnotes: yes this change.