This looks good.

I've considered Marius' suggestion. I reject it. memmove is now a first class citizen. If you'd like to make it even better, you are welcome to do so after this commit.

We only need to generate about 8 bytes of entropy per second total for the spiking of the algorithms...

In D15517#327757, @mav wrote:

Looks good to me. The only rough edge I see is that outstanding_cmds is used only for the newly added assertion, that is why it was so broken before this and nobody cared.

OK. So it looked easy...

doh! no, with invariants

doh! compile with invariants

I agree. Comment says this was from nvme_scan_lun, and it uses path here not periph->path.

Regroup

fix bogus mdastart -> ndastart

Fix missed part of the patch

I have a straw-man patch that does some of what mjg is talking about. It doesn't remove the b* functions though. It's not quite ready for sharing, though if there's interest i'll polish up enough to publish.

OK. Can't find anything else to argue with :)

Despite a couple grumbles, this looks good to my eye.

We can change to M_TRIM when Kirk commits his stuff :)

In D15430#325814, @seanc wrote:

I want to point out that the lack of code formatting tool like clang-format resulted in @markj spending some of his precious cycles reviewing not the substance of the patch, but instead commenting on style nits (correct according to style(9) - thank you @markj).

Using brain power for code formatting is the modern-day equivalent to creating fire by rubbing two sticks together instead of using a match/lighter. My comment isn't directed at anyone in particular, but is an observation from watching and participating in reviews in FreeBSD (vs other repos and orgs in my daily patch review queue where the review process is nearly 100% focused on the substance of the patch and not various nits that are caught by linting tools and formatters). I apologize if this sounds flippant, that is not my intent. I'm excited to see changes like these land but wish the friction of style(9) were obviated through modern tooling. This isn't a new comment to most on this review but I wanted to vent a little feedback.

This approval is for a 'looks like you got it all and did the removal properly' aspect of this review.
I personally agree we should have removed this a while ago.

Looks good to me. One tiny question that occurred to me after I looked at it this morning. I think we're fine delaying the close for up to a tick so we don't have to try to send a bunch of wake ups during normal operation. Also did the obligatory lock check, and we're good there as well: refcount is only changed while holding the periph lock, and cam_periph_sleep uses the same lock to sleep on.

This looks good to my eye. I'd give mat@ 24 hours to opine on your changes in response to his comments.

Looks good to me. I don't understand mat@'s comment. It looks stale, but if not my approval is contingent on you resolving it.

In D15169#324670, @trasz wrote:

Perhaps have a common file (can't help but notice it seems to be the only per-arch etc/ file, so we could get rid of the whole mechanism this way), and have per-image overrides specified by release/*/WHATEVER.conf files, like the rest of per-image things?

looks like you've removed a lot of keywords...

This looks good. One minor concern about precedence, but if it's good, I'm good.

In D15378#324222, @kib wrote:

IMO it is more useful to check the ${LD} features, or at least the ${LD} version.

Update after committing the low-risk deck-chair motion.

not quite done.

In D15169#319736, @trasz wrote:

I'm pretty sure we have MIPS boards (well, BERI running in FPGA, but still) with Terasic... screen-thingys with console on them, here at Cambridge. Not sure how it's configured regarding ttys(5), though, or if it even goes through vt(4) - although it certainly looks like a text console.

Update to actually remove libkern/mmemmove.c

Mroe stuff?

Almost right...

Generally I like it.
I'd like it a lot more if there were man.9 page(s) for the epoch API.
Some nits are all I see, but my CK foo is weak.

You'll need to rebase after my push. Sorry.

I think you can close this.

In D15326#323264, @sbruno wrote:

In D15326#323223, @imp wrote:

In D15326#323185, @sbruno wrote:

In D15326#322966, @imp wrote:

So why isn't sys/ctypes.h enough? you're introducing a dependency on userland inside files that look like they are used by the kernel.

Ugh. This didn't occur to me as this was part of the buildworld stage. How about I add a "#ifndef _KERNEL #includ <ctype.h>" type thing. sys/ctype.h doesn't have all of the same ctype macros that are in /usr/include/ctype.h ... so that might be a problem.

why doesn't sys/ctype.h work? We should fix that problem...

Unless I'm super confused here, this is part of buildworld ... so _KERNEL isn't defined, therefore the include does nothing?

In D15326#323185, @sbruno wrote:

In D15326#322966, @imp wrote:

So why isn't sys/ctypes.h enough? you're introducing a dependency on userland inside files that look like they are used by the kernel.

Ugh. This didn't occur to me as this was part of the buildworld stage. How about I add a "#ifndef _KERNEL #includ <ctype.h>" type thing. sys/ctype.h doesn't have all of the same ctype macros that are in /usr/include/ctype.h ... so that might be a problem.

So there's already this at the end of the file: