Note: the manual for this card is a bit ambiguous on this point, but the implications are there...

Lgtm

I think this is fine.

OK. I did the following:

I'll test this on my arm64 box... I'll also try hack things to put a 'sleep 30' into the generation of wayland-client-protocol.h to exaggerate the race.

In D23644#519909, @jbeich wrote:

@pkubaj, @mikael, can you test build on powerpc64 and aarch64 on real hardware?
I'm trying to figure out if https://gitlab.freedesktop.org/wayland/wayland/issues/144 is due to qemu-user-static.

Update, per scottl

I'm cool with the parenthetical form.

this looks promising...

Thanks Jan. I like this direction.
There's two build errors that look easy to fix (or I'm misreading the logs). What are you plans there?

I think the .St -isoC-99 is better than a raw C99. Otherwise, I like the prefers.

If you make the changes you say, this looks good to me

I'm up for this... you can add me as a maintainer

We'll fix a different way

In D23541#516977, @scottl wrote:

In D23541#516975, @mjg wrote:

In that case what about the console spam? I presume messages of this sort:

g_vfs_done():md10a[UNKNOWN()]error = 45

stem precisely from this. This happens to really spam the console for me when e.g., running stress2 when at least for this case it should never print anything. iow it looks like a design error that that devices which don't support something can get a request AND fail resulting in an error message.
Here is an example from pho's log: https://people.freebsd.org/~pho/stress/log/mark125.txt

Good point, the block layer shouldn't be spamming like this.

In D23541#516965, @scottl wrote:

In D23541#516964, @imp wrote:

In D23541#516955, @scottl wrote:

I agree with Alexander, I really don't like that this perpetuates bad design.

So the proper fix is to fix all the disk drivers to just return op not supported?

Yep, gotta bite the bullet sometime

--- scsi_da.c	(revision 355435)
+++ scsi_da.c	(working copy)
@@ -3381,6 +3381,10 @@
 			}
 			break;
 		}
+		default:
+			biofinish(bp, NULL, EOPNOTSUPP);
+			xpt_release_ccb(start_ccb);
+			return;
 		}
 		start_ccb->ccb_h.ccb_state = DA_CCB_BUFFER_IO;
 		start_ccb->ccb_h.flags |= CAM_UNLOCKED;

In D23541#516955, @scottl wrote:

I agree with Alexander, I really don't like that this perpetuates bad design.

In D23541#516766, @mav wrote:

I won't object too much, but first addition of quite specialized command and then workaround for it does not make me particularly happy.

In D23541#516762, @mav wrote:

I would honestly prefer drivers to report reasonable errors on unknown commands. That would fix the issue once and for all.

In D23526#516647, @rgrimes wrote:

A document describing the language and process of depreicating would be good to have.

update, per ed's comments using brooks' wording from 10M nic removal.

Will commit with the usr.bin/Makefile changes suggested.

I like it, and agree with the other comments you've already said you'd address.

This is the least sucky way to fix much of the breakage as a stop gap to the final solution

In D23403#513670, @rgrimes wrote:

Shouldnt the driver code include a gone_in?