I see an opportunity for documentation improvement here. :-)

Does Kerberised telnet still work after this? ISTR (many years ago) that a successful compile does not necessarily mean a working binary due to similarly named libraries.

In D10048#215609, @des wrote:

Please allow me some time to commit my Chacha20 implementation first so we can use that instead of the legally dubious version which is included in this patch. I hit a snag that I haven't had time to debug, but I'm hoping to have it done by Tuesday.

Address reviewer comments.

In D10048#209666, @rwatson wrote:

In D10048#209661, @markm wrote:

RWatson: Not to get picky or anything, but there was already a malloc() in that place.

I've misread the patch; I'm happy for this to be fixed in a separate commit. I'll continue to sort out a DPCPU man page, however.

In D10048#209666, @rwatson wrote:

In D10048#209661, @markm wrote:

RWatson: Not to get picky or anything, but there was already a malloc() in that place.

I've misread the patch; I'm happy for this to be fixed in a separate commit. I'll continue to sort out a DPCPU man page, however.

RWatson: Not to get picky or anything, but there was already a malloc() in that place.

In D10048#209647, @rwatson wrote:

Your commit introduces per-CPU memory allocation.

In D10048#209623, @rwatson wrote:

In D10048#209275, @markm wrote:

• I feel that using sleepable mutexes here is fine -- the difference in performance is negligible on most contemporary microarchitectures, and there is an argument for moving some of our other critical sections to being mutexes (e.g., per-CPU UMA caches).

I'm concerned about cpu migration. Mutexes don't guarantee that a thread will stay on the same cpu, right?

This is correct: you must make sure that you continue to access state on the CPU for which you acquired a mutex -- e.g., by caching a pointer to the per-CPU state you are accessing, in case migration takes place.

In D10048#209125, @rwatson wrote:

Just a few quick comments:

• I find it confusing that the new code is in a file named arc4random.c.

I'm not comfortable with critical sections for now. Back to mutexes
as before. I'm happy to revisit this later.

Address review comments.

Respond to reviewer.

Address review comments.

Reply to reviewer.

Reply to reviewers.

Address review comment.

In D10048#207892, @lattera-gmail.com wrote:

I can do a pkg exp-run with this patch on HardenedBSD's infrastructure tomorrow if desired.

In D10048#207864, @jmg wrote:

This will cause issues on platforms that do not use loader. We do not require loader on all of our platforms, and those that don't will have issues w/ the way chacha is started. As there is not an error (continues), this creates divergent behavior.

Final tweeks; tidy up some stuff and add bootverbose startup
reports.

Add 'bootverbose' printfs.

Respond to reviewer remarks.

Fix reviewer concerns.
Add boot-time entropy usage for first (re)seed.

Reply to reviewer.

Reply to review comment.

Add an SVN-friendly commit message template.

Adding the FreeBSD SO.

Fixed a missing word typo in the title.

Looks good to me.

Add SO

I really like the direction. One minor nit which is more of a question than an objection.

I've got this ready to commit.

Thanks for this, BTW :-)

Looks OK to me.

I'm still Happy!

I'm happy.

This was on my TODO list. I wish I'd known it was this simple!

I am glad to see LOCALBASE is part of the deliberations.

I’m nearly there - there are a few more of them too!

Massage this into a more commit-worthy version; document what is going on and provide SDT probes to assist adopters.

Thanks reviewers!

Review nits from bjk.

Thanks, bjk!

Add example module.
Move common _write functions to mase of module.
Remove unused functions.

Thanks J-M!

Address review; tidy up the opt_*.h includes.

Address jmg review comments.

Thanks JMG.

Thanks Warren! (wblock)

What the hell is 'manpages' doing, blocking immediately on diff upload? Rogue script?

• Add DEV_RANDOM pseudo-option and use it to "include out" random(4)
• Update documentation for random(4) modules.

Incorporated with edits, thank you!

I removed 'manages' as an auto-reviewer - it gave a thoroughly broken scripted review.

I am now seeking formal review for this please.

• Add DEV_RANDOM pseudo-option and use it to "include out" random(4)
• Update documentation for random(4) modules.

Build tweeks to make "make universe" work.

In D3354#68413, @delphij wrote:

I have only glanced over the code and it seems good overall.

In D3354#68411, @jmg wrote:

Are you opening this up to more reviewers? Or still only for SO (aka delphij)? The reason I ask is that secteam only consists of delphij, so adding secteam doesn't add any new reviewers.

I'm not soliciting reviews yet except from delphi (AKA SO). When I'm finished testing, I'll open up for reviews.

• Make the UMA harvesting go away completely if not wanted. Default to "not wanted".
• Fix comment as per review suggestion.

In D3197#64019, @delphij wrote:

I like the idea, but it looks like the new version doesn't have the random.h changes. If combined with the sys/conf/NOTES, sys/conf/files and sys/sys/random.h changes in the first version of changeset, then consider this as an "Accept".