I like this a lot better. I can't think of any special case I/O we'd need to make an exception on. All the normal commands are what you'd want to block. The abnormal ones are things like FD_FORMAT which will screw things up, but completing the command won't screw them up worse, so that's good. The BIO_ZONE stuff is done via ioctls which won't screw up if we don't complete it. I'd like it if we could allow some clients complete and others be blocked, but that's somewhat beyond the scope.

Dang, sorry I stepped on this review with my commit. I missed it somehow. Glad you liked mine better, but I would have coordinated had I noticed this before now.

These look good. Sorry for my screw up on the review number.

In D15628#330215, @dim wrote:

• Use -march=i386 instead of -mcpu=i386 in defs.mk. The gcc documentation states that -mcpu is a deprecated synonym for -mtune, but -mtune does not prevent instructions "higher" than i386, it merely tunes for them.

This was committed as r334413-r334416 which were tagged with the wrong review number.

I'm sorry, but it looks like my change replaced this review...

wrong review

In D15592#330118, @mav wrote:

I can't say that I like it, but it makes sense to me.

Proposed biodone() to me sounds like too high level to handle this, since GEOM transformations can be complicated enough to corrupt the system state. Plus some code like ZFS may not use it at all.

update.

No, we've always just used efiFOO for the efi programs.

So I'm still uneasy about this.

The concern I have for UEFI + MBR is one of FreeBSD support, not BIOS support. There are some places that assume GPT partitioning, though that may be just in the efibootmgr code which just sets boot efi variables.

Multiple disks require that we don't use globals.

Updated to address comments

Better comment about GPT case

Address Ed's comments

Doh! blocks, not bytes, for this arg.

Thanks for doing this...

Do we also need an entry in ObsoleteFiles.inc?

Generally, I like this. It mirrors efforts to have userland drivers. The only area I see missing after this is interrupt delivery to userland processes.

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.