split INTRNG main file into two files #1285
Conversation
|
I'll confess this is mostly meant to suggest there really is another interface being hidden here. Mainly |
|
Gah! Keep trying to draw a borderline and some bits are quite unclear. |
|
This is an alternative. I'm pretty sure I've got |
|
I'm rather unsure where the border goes here. To tell the truth, right now I'm primarily interested in the two at the front. I'm trying to port a driver for an unusual PIC. Due to extra knowledge about its bus, the implementation skips some steps and therefore doesn't match to INTRNG's existing interface. |
ehem
force-pushed
the
split
branch
2 times, most recently
from
fe033e5
to
561b878
Compare
intr_describe_irq() was mixing two operations together. There was the mapping step and the underlying intr_event_describe_handler() call. Split these two steps apart to match other portions of the interface. Differential Revision: https://reviews.freebsd.org/D39333
Use of the macro CK_SLIST_EMPTY() on ->is_event->ie_handlers readily substitues for the value ->is_handlers. While only minor shrinkage of struct intsrc, small reductions do accumulate. Update the i8254 hack to work with this setup.
Making INTRNG's intr_add_handler() act similarly to x86's would be a bit troublesome. As such modify x86's functionality. Currently INTRNG uses a bit array to indicate processor restriction, so remove the domain to allow matching.
Specialized peripheral PIC drivers may need to handle most interrupt setup steps themselves without touching newbus. Two cases are intr_add_handler() and intr_describe() which are internally used by `intr_setup_irq()`/`intr_describe_irq()`. Exposing these allow for alternative use case. In fact the BUS interface for INTRNG is arguably a layering violation. Those 6 functions could just as well be in nexus.c or a kernel library. Differential Revision: https://reviews.freebsd.org/D39333
Handle the situation as a request to update the interrupt table name, without updating the event name.
intr_teardown_irq() is PIC-level, while intrcnt_updatename() is interrupt-level. As such, intr_teardown_irq() should use the next layer of function, instead of an interrupt-internal function.
intr_isrc_assign_cpu() failed to split the intr_event functionality from the assignment functionality. The actual assignment is a PIC-level operation and as such should be separate.
Using isrc_table_lock for these functions violates layering. Instead use pic_list_lock, which isn't quite proper, but matches the layer these functions are located.
This should serve to truly split things into layers. Perhaps this could then be used on x86 and serve to continue unifying interrupt frameworks.
Hopefully SSIA. INTRNG presents multiple interfaces and tries to hide some. There seems to be a border between the PIC side and the event side. Split these two apart.
The PIC side bears fair resemblance to what is in
x86/nexus.c. I suspect it might be possible to have this take over some of what is done for x86. Theory is to shrink the architecture specific bits.