I'm keen on having this - a build is under way. DHYB, it may take a while.

I'm happy to see this landed in disabled form.

I'm happy to see this landed in disabled form.

LGTM.

I like this general idea very much! I'm a bit leery of the critical regions, but I admit that I don't understand them properly. I presume that in a PCPU environment they are fine.

OK to close again.

That works, thanks! I'm at latest CURRENT, no backouts, my console works and so do my PCI ethernet port.

ECAM hacks? When are those likely to appear? :-)

With this patch in, AND the flashe given above, I get my console back!

Worse. Previously working console now broken. Current with this change backed out now broken.

Trying now. In the meanwhile, is there some place where the Collected Wisdom™ of all current mcbin firmware statusses, hints, binaries etc are kept?

Yup - my flash is a couple of months old, and a hand-rolled debug-version (not by me). The image you pointed to fails with checksum errors at boot, but it may have something to do with the way I made it. With the same MBR as the old one, I did:

This change breaks my MacchiattoBin DoubleShot. I've bisected to get to commit r362574, which is this. The symptoms are a hang right at the beginning of the boot, at this point:

Happy with this.

If a committer is needed, I'm happy to oblige, but I'll need testing time, and for that I need to build and boot. If Someone Else(™) can assure me that this works, I'll speed it up a bit.

LGTM, modulo delphij's comments.

I like the direction this is going, but I'm still reading the design papers.

LGTM

I can't find anything to object to - but my epoch-fu is a bit lacking, so I'm trusting the other reviewers here.

I'm delighted with the amount of OS-interface and locking code that is removed!

This is a GREAT step forward, so I'm happy to accept it as such. The objection to #undefs is stylistic/idealistic, so you may ignore it at your pleasure.

I've been running this locally too.

No-brainer.

The whole change LGTM, but please go further and remove RANDOM_LOADABLE altogether if the consensus allows!

LGTM

*LIKE*

Shows how much I know about sysctls :-)

Please upload diff with full context.

No objection to the logic, just the user-facing wording needs to be "de-geeked" a bit! :-)

Clarifies the logic a bit. LGTM.

Very small complaints only.

LGTM otherwise.

Presuming all the testing works :-)

Still LGTM :-)

No objection from me.

None job, thanks!

Good catch!

Good move!

This is a step in a direction that I've been wanting to doo for quite some time; pin multiple output generators to processors. There is more, but I need to write it in detail first.

Looks OK to me!

I'm OK with this.

LGTM.

Against my better judgement, I kept the !DEV_RANDOM case as some folks insisted on being able to use preferred tools (ssh) even on insecure embedded hardware. I'm happy to se you fix it, if it means I don't get the flak ]:->

I'm happy with this, in principle. I defer on the kernel innards, but the general engineering looks sound.

Accept with delphi's changes.

OK. I like these diffs even better.

You need the security officer's say-so. I have a personal wavier when I do such commits myself (as I wrote the main random device), but this is non-transferrable, as far as I know.

LGTM.

Very good!

Nice work! Out for interest, why make the output generator selectable? Why not switch completely to Chacha20?

Overcome By Events.

I like this!

OK.

Looks good to me.