kern/intr: allow for event allocation outside kern_intr.c

[ehem_freebsd_m5p.com]

Summary

In some cases it may be better to allocate the intr_event structure
outside of kern_intr. Notably if an interrupt controller needed data
attached to the event instead of the PIC.

[ehem_freebsd_m5p.com]

The idea is some interrupt controllers are very dynamic. Some need to change their interrupt assignments on suspend/resume. For such controllers it seems to make more sense to keep device information attached to the event structure, rather than the architecture interrupt source structure. This would allow such dynamic controllers to swap interrupts around without needing to copy data attached to the source structure.

[ehem_freebsd_m5p.com]

sys/kern/kern_intr.c

302–303

I kind of want to put a KASSERT(event != NULL, ("%s(): NULL event passed in", __func__)); at the top of intr_event_initv() and remove these two lines. The event being NULL seems nonsensical.

[ehem_freebsd_m5p.com]

Any reviews for this? While it will take a while to make use of this, I have a definite use for this. I was actually hoping for progress, not merely silence on this.

If there was a desire to keep all struct intr_event structures in the M_ITHREAD pool, an alternative approach would be to instead add a size argument before the format argument. If the size is zero, allocate sizeof(struct intr_event), if non-zero allocate that much memory (then KASSERT(size >= sizeof(struct intr_event))).

The goal is often data is attached to the various architecture interrupt structures, but in some cases that data is better attached to the event. This is valuable for dynamic interrupt controllers which have to be reprogrammed after system suspend; the events could be shuffled to reflect where the interrupting devices moved to, instead of shuffling the architecture interrupt structures. I don't know for certain whether this would actually improve things, but it certainly looks to have potential.

[ehem_freebsd_m5p.com]

Thoughts on D35417?

[ehem_freebsd_m5p.com]

I'm distinctly unsure of the idea presently. I would like to get things better merged together, but for now other things take priority.

[ehem_freebsd_m5p.com]

This is part of a fascinating end point I reached in combination with other commits. Specifically, Github #1457. I think this is better to review via GitHub, since the full git support allows viewing as part of the full series. Phabicator isn't all that well suited to the role.