Several x86 interrupt core functions were already operating on intsrc
structures. Now switch the remaining 4 to intsrc for consistency.
Details
Details
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Passed - Unit
No Test Coverage - Build Status
Buildable 56127 Build 53015: arc lint + arc unit
Event Timeline
Comment Actions
Came up as part of guess what. Upon examination it turns out the Xen event channel (interrupt equivalent) code only needs to preserve the interrupt number for calling intr_add_handler() and intr_describe(). Add variants which instead accept the struct intsrc and the Xen code could simply discard the interrupt number.
The one issue is where the isrc == NULL check should be? Should the _intsrc variants be able to deal with being passed NULL sources?
Comment Actions
I should add, intr_bind() and intr_config_intr() also seem good candidates for this treatment. I though cannot cite any places which would currently benefit from the functionality.
Comment Actions
Given that the amount of churn involved looks to be minimal, and since some of the public functions here already operate on intsrcs, I would suggest simply changing the existing functions to take an intsrc, and then handle lookups in nexus. intr_lookup_source() is already used extensively in consumers.
The one issue is where the isrc == NULL check should be? Should the _intsrc variants be able to deal with being passed NULL sources?
Existing intr_* functions which take an intsrc do not perform such a check, so I would not attempt to handle NULL in the new variants either.
Comment Actions
Updating per @markj's comment. I'm unsure whether any portions of the nexus code can assume the interrupt number is valid and skip the == NULL check.
Comment Actions
Available in a form handy to git at https://gitlab.com/ehem/freebsd-src.git branches "D35386" and "D35406". I suspect I'll be asking @royger to push fairly soon though.
Comment Actions
Due to D36901 getting in first, intr_bind() has disappeared and the portion of D35386 adjusting the interface disappears.
I'm awfully tempted to switch the order of intr_add_handler()'s first two arguments to make the interface more consistent. This also moves x86 closer to INTRNG (the opposite could be done, but I feel INTRNG got this one right).
No activity since I don't have a commit bit of my own.
Comment Actions
Due to D36901 getting in first, intr_bind() disappeared. As threatened, I really like intr_add_handler()'s first two arguments being in the opposite order. Not only does this seem more consistent with the rest of the interface, but this also matches INTRNG (the domain argument is now the only difference).
Comment Actions
Update to better reflect current state of FreeBSD tree. My repository had several patches, one of which had modified intr_describe(). As such this better reflects current state.