I'd still be tempted to put it in files and just spike 32bit builds. Sure, you can put it in the config file and yhe error is delayed until you build, but that's ok imho. Lots of things in files that don't work evertwhere. No need for a files.64.

I guess this is OK.... It's consistent.

So a few words about why this is useful. Our KBI commitments on 15.x is fuzzy at best. What does this enable?

More than 5, this is overdue

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?