Being in the "machine/" directory already indicates these headers differ
from machine to machine. As such the shorter name "intr.h" is
appropriate. This also matches the INTRNG machines for the header name.
Details
Diff Detail
- Repository
- rS FreeBSD src repository - subversion
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 46072 Build 42961: arc lint + arc unit
Event Timeline
So the theory is to continue pushing the various interrupt handling implementations closer together. I suspect the INTRNG team may have thought "intr.h" would distinguish their system as being potentially machine-independent, but I think this simply serves to inhibit merging.
As such a case of choosing "intr.h" versus "intr_machdep.h". I think "machine/intr.h" is better as "machine/" already marks them as potentially having architecture quirks. Ideally their similarity will increase, but this will take a while.
If it is felt __FreeBSD_version should be incremented and then check for header name, I've got that prepared. Simply an issue of need a reviewer to request that be done.
Ping for D35559. This will be in the way of most attempts to further merge the interrupt interfaces, so deciding the direction would be helpful.
So, most approaches to getting interrupt subsystems to converge are going to need something along the lines of D35559 at some point. Might it be possible to get a decision/activity on D35559?
My thinking was the shorter name machine/intr.h was better, since being in machine already marks the header as being potentially variable from architecture to architecture. Yet the opposite direction of moving arm(64)'s headers to machine/intr_machdep.h would also work. This really needs a decision as forward progress on convergence might be possible if there was activity here.