Not quite sure what the "via" part means as normally I'd take that to mean that "xregs" were being delivered or provided by "sig" and I think this test is more about the fact that signal context properly saves/restores "xregs"? Maybe consider dropping "via"?

In D40099#917174, @dchagin wrote:

In D40099#914847, @jhb wrote:

I wouldn't mind spelling out "decimal".

ok, thanks. are you ok if I change native syscalls (signals related, for start) too?
by separate chang of course

I suspect the idea was you could examine it via gdb or the like during early development, but it doesn't serve a purpose now.

Thanks for doing the other changes.

In D40048#915407, @jrtc27 wrote:

I'm happy to do that if consensus is that's better, I just felt that it's better to give a hard error for something that's been removed as an option rather than warning that the option that used to do something now doesn't do anything but continuing onwards. I guess it depends whether people are doing weird things with -k; if they're only using it to work around the lack of full paths then ignoring the option will do the right thing, but if they're using it to map onto some other directory that doesn't match the full path then it'll do the wrong thing. Probably we're in the former category though, especially given how little pmcstat actually gets used...

I feel like the worst offenders are really when you have to #ifdef for both for LINT-NOIP. Another tact we might consider is just axeing LINT-NOIP. I can see some value in LINT-NOINET so an INET6-only kernel remains clean, but I see less value in LINT-NOIP and I feel like more of the cost is for that config.

I'm would be fine with just removing it from the default install flow but leaving it around if a user wants to go look at it. I'm also fine with axing it entirely as this does. I would be less of a fan of changing some of these behaviors by default.

Thanks for catching this.

I'm inclined to agree with @jkoshy with emitting a warning for -k for stable/14, but the error from usage for an unknown option might be just as functional in practice.

Actually, my bad, I already enabled the warning for this in main. I have another warning I'm enabling and the exp-run for the second warning found this breakage from the first (I guess the module was broken for some other reason at the time I ran the earlier exp-run).

In D40171#915122, @ale wrote:

Just to know, is this required by a compiler update?

I wouldn't mind spelling out "decimal". File descriptor arguments are also good candidates for always printing as decimal BTW.

Yes, the intention was to only install the one header needed for userland, not all of them.

As noted in IRC, I think it would be nice to apply the same only_if clause to other automatic jobs as well and provide duplicate manual jobs for those also that developers can request in their own fork.

While I prefer the tab alignment, the style in the broader community that uses dashes is to not do the tabs either, and in particular that would be compatible with using git commit --trailer

I must admit I am quite used to the color output and depend on it to stand out accepted from needs review, etc in the list output. I kept the colors intentionally in the original version of list.

I guess it's fine to merge.

A few suggestions, but looks ok to me otherwise.

It would be good to update the commit log now to reflect the new status? This does seem like a fairly nice fix and much nicer than the other approaches I had considered.

I think that approach is fine for now, and it lets us stage things into the tree more gracefully.

In general having a working version of this would be really nice.

Perhaps adjust the commit message to say something like "Failing to preserve pir_desc can result in pending interrupts being lost on resume leading to a hung VM" or some such to clarify that the hang is due to missing interrupts.

Hmm, does this mean 'git arc list' no longer lists the colorized output it did before?

Ditto on "$@". :)

I think an osreldate check is ok. I already have to add one now to deal with arm64 struct layout changes in 14 anyway.

Humm, this needs to unpush the target on error now. There is a helper class to do that for you that uses RAII (you reset it when you've finished setting up the target).

The raw errno value would require a stack buffer to hold the formatted string which is my guess as to why it's just "other error" (and the original version Ed had didn't have the other error text even). I think if the other error case can be figured out via dtrace that using a static string to avoid the stack buffer is an ok compromise.

In D39921#908767, @kib wrote:

boolean_t is the mach' type AFAIK. I am curious why making this change.