• Rework suspend / resume time keeping.

In D26122#580009, @cem wrote:

In D26122#579979, @imp wrote:

That's an interesting approach... I'll noodle through that and post a new version.... ah, the only question I have is how big is too big? If we can do 1k on the stack, maybe we should just do that all the time... if not, what's a good limit?

We can probe remaining stack with GET_STACK_USAGE()... I don't know if/how much we need to leave for interrupts, and we need to leave a few bytes for whatever devctl_notify() does, but that at least gives us a heuristic for "is a large stack buffer reasonable?"

In D26122#579967, @kib wrote:

This makes the mechanism even less useful.

All commits this time, eh?

Fold in feedback from reviewers

feedback applied

Probably closer to ~2000 for the cut-over date. Toolchains in the 90s did support indexing, but I ran into several cases where lorder helped even though it shouldn't have... That did stop being the case sometime in the early 2000s, though... At least for static libraries. Dynamic ones did indeed work from about the mid 1990's w/o ranlib/tsort/lorder. Linux's a.out libraries being the last one I recall where that was beneficial.

This version looks good to me.

This all looks basically sane, subject to my usual worries about it breaking native builds... :) I didn't see anything that would, though.

No comment on the list of options, but the method being used is proper.

Tweak mount to compile :)

Move everything to vfs_mount.c and simplify, per suggestions from kib@. Also do
a nowait alloc of the buffer, even though it might not strictly be needed after
the shuffle.

Right idea... blah blah blah... :)

In D25967#575683, @arichardson wrote:

In D25967#575682, @imp wrote:

In D25967#575668, @arichardson wrote:

Copying instead of creating links *should* be fine. However, I vaguely seem to recall this previously caused issues for bootstrapping macOS since one tool wanted to find something relative to realpath argv[0]. Will check if that's still the case tomorrow morning UK time.

Sure thing. I included you because I had hoped to get this perspective. On Mac/Linux, only the incompatible tools need to be bootstrapped, and they will use $HOST libraries always, no?

Yes, and they default to BOOTSTRAP_ALL_TOOLS.

In D25967#575668, @arichardson wrote:

Copying instead of creating links *should* be fine. However, I vaguely seem to recall this previously caused issues for bootstrapping macOS since one tool wanted to find something relative to realpath argv[0]. Will check if that's still the case tomorrow morning UK time.

quick sweep. This is kinda large and hard to review, so I also suggested a few 'carve outs' that could be committed independently.

I think this may be OK. The only real heart-burn I have is the xpt_async ...

The matches the tuhs archive too...

Happy to hand it off, said so in the bugzilla, feel free to proceed with my fullest possible blessing.

In D25538#571162, @koobs wrote:

@imp I've approved (ports) the updated patch in the bugzilla issue

Is this ready to go? I've been busy with personal stuff the last few weeks, but could do this if we're ready... And is this patch identical to the one in the bug or not?

cute

These all look good to me. Might want to wait a little on Scott since this is semivendor code and there may a hidden reason for these...