Page MenuHomeFreeBSD

intr: rename "machine/intr_machdep.h" headers to "machine/intr.h"
Needs ReviewPublic

Authored by on Jun 23 2022, 1:27 AM.
Referenced Files
Unknown Object (File)
Apr 26 2024, 2:52 PM
Unknown Object (File)
Apr 22 2024, 7:35 AM
Unknown Object (File)
Apr 17 2024, 10:28 AM
Unknown Object (File)
Dec 29 2023, 1:31 AM
Unknown Object (File)
Dec 20 2023, 4:15 AM
Unknown Object (File)
Dec 18 2023, 12:24 AM
Unknown Object (File)
Dec 10 2023, 8:32 PM
Unknown Object (File)
Dec 1 2023, 2:48 AM



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.

Diff Detail

rS FreeBSD src repository - subversion
Lint Passed
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.

I was under the impression D35559 has the right reviewers, but no action has been observed. This is meant as a precursor to the updated D32504. This can improve several places, but does need someone to okay (and commit to the main tree). Then there are the child commits.

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.