Ok. This makes good sense. I'd be tempted to return 0 rather than err, but both are fine.

Yes. We need a way to export all the data for libxo in one path, not the twisty maze which we've gotten wrong so many times.

yea, I'm generally OK with it, but my question about the code remains... Though I have a vague memory of another review that was more complete somehow. I was worried it would break FreeBSD code, but no code in the tree would be broken by it.

From a historical perspective, I'd prefer fastboot == reboot -f. However, that ship has sailed and we're stuck with either preserving a lot of the current behavior with reboot -f checking or also overloading it with fastboot. Or moving the force to -F. I hate myself that I added -f, but it can't be helped. So fastboot is the least bad choice, imho.

I have a vague notion of doing this before...

In D54117#1236396, @des wrote:

In D54117#1236374, @imp wrote:

This is what I've wanted to do for some time now. I didn't look closely enough, but so long as fastboot gives us the current behavior, (aka the -f behavior), I'm good with all this.

That is not currently the case, but that's fixable.

This is what I've wanted to do for some time now. I didn't look closely enough, but so long as fastboot gives us the current behavior, (aka the -f behavior), I'm good with all this.

Offline we talked. I'm totally cool with whatever so long as I can override the forced clean.

So I need to make sure there's not a blast radius on this one.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

Update per review and rebase over resize changes... woof.

ISO_C_VISIBLE: Interfaces available. It's set unconditionally based on the dialect. It's an undocumented interface.
STDC_VERSION: the exact dialect being compiled for. This is standards defined.

Why can't we make virtio_p9fs.ko depend on p9fs.ko? That would also cover this case, no? And would confine their visibility to that one module, no? It's how we do pci, etc.

Is it possible to create a branch for the whole chain somehow?

Looks generally good, but I did have one question...

both user and kernel, though there's no MK_REPRODUCIBLE_BUILD for user.

better wording for the triv copy routine

mixes a couple of different things, but they might not be as independent as I'm thinking, so I think this is fine from that perspective.
The workaround looks to match the one in Linux well enough I think it will work. The code bases are different enough that I didn't do a detailed copying analysis since direct copying between these drivers is kinda hard in structure, but is easy because the #defines are necessarily the same which has little to no copyright protection.