Fixes to1363 problems #1431
Open
Fixes to1363 problems #1431
+333
−319
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
It's late here and I'm off to bed. I'm on travel tomorrow and may be jet lagged tuesday, and I'll look at it first of the pull requests. We have a lot of time before the branch to refine and I spent time at EuroBSDCon recruiting reviwers. I wanted to let you know quickly my schedule. |
|
On review seems the one which had been in the middle really needed to be first. Dunno about others, but there seems a phenomenon the first commit usually needs to be last and the last commit needs to be first. |
|
I'm unsure the last one really needs to be part of this. Simply a fragment of where I think things are going, simply illustrating what I was thinking of. |
|
While I'm not too hopeful about the latter two right now, I hope the two at the front can go in now. |
ehem
force-pushed
the
fix1363
branch
5 times, most recently
from
f7717dc
to
cbb96fc
Compare
Switch to INTR_ROOT_COUNT as this better matches the purpose of the value. Remove the default from the core. Better to require the architectures to declare the type since they will routinely deviate and a default chosen now will likely be suboptimal.
This reverts commit 4f12b52. Unfortunately having the unusual #include direction serves a high-value purpose. The <machine/intr.h> headers almost serve as a standard point to retrieve architecture interrupt headers. This is far more valuable. Leave the move of #include <sys/bus.h> in riscv/trap.c intact. That is a reasonable move unrelated to the purpose of this revert. Move the #include of sys/intr.h earlier in arm/include and riscv/include. There was likely a historical reason for this being towards the end, but there appears no reason now and this matches arm64.
Various files #including INTRNG interrupt headers were inconsistent in whether they #include'd sys/intr.h or machine/intr.h. Since there is a need to work with other architectures, move to #include of machine/intr.h. Modify sys/intr.h to #error if machine headers are included first and future uses match this. Remove #include of intr.h where possible. Sort of fixes c85855a. The breakage was out too long.
Having two distinct names for the interrupt headers serves to interfere with most efforts to converge the interrupt frameworks. Simply rename all of them to "machine/interrupt.h". Define __MACHINE_INTERRUPT_H__ in i386/include/interrupt.h in order to be consistent with other platforms. This is otherwise silly, but consistency is important. Remove the #ifdefs in subr_bus.c as a precursor to making c85855a useful on other platforms. Do some sorting of #include order. Notably a bunch involving resource.h. Differential Revision: https://reviews.freebsd.org/D35559
For code which doesn't care about the underlying structure and simply needs to have a common name. Differential Revision: https://reviews.freebsd.org/D39178
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is kind of urgent as I had been wanting some of this with #1363. Finally spotted the overt assembly to C bridge and that works better for things meant to be shared.
Hopefully got the headers right. Turned out to need
LINT-ACPIto find the combination which actually triggered the one condition.This is kind of urgent-ish.