intrng: allocate event during isrc setup

[ehem_freebsd_m5p.com]

Summary

There is minimal benefit in delaying event allocation. Worse, this
reduces opportunities for merging architectural interrupt structures
together.

[ehem_freebsd_m5p.com]

Seems pretty reasonable to do lazy allocation of struct intr_event, but there are circumstances where it could be a disadvantage. The other likely allocation time is during the setup step, so using a flag seems appropriate. The question which comes to mind is, which flag value should be used? Should this use a high flag number since this could be discarded after the setup step? Be strictly sequential?

[ehem_freebsd_m5p.com]

Appears intr_isrc_register()/intr_isrc_deregister() would need to be after isrc_event_create(). I'm unsure whether to move the former down versus the latter up. Right now I'm mostly interested in whether this seems reasonable.

[ehem_freebsd_m5p.com]

I've been concerned over whether the initial version of D40166 would pass. The use case was too specialized. As such an update, remove the lazy interrupt allocation.

I don't know what benefit lazy interrupt event allocation is supposed to confer. In nearly every case the event will simply happen later. More importantly this allows one to assume all initialized interrupts have an event. No more special case for architecture-agnostic things.

[ehem_freebsd_m5p.com]

One extra may be needed for this. The file sys/arm/mv/gpio.c has a call to intr_event_create(). Unfortunately this isn't setup for INTRNG allocating events early. Interestingly it seems ad2be10ff043 is exactly the same issue I'm running into.

[ehem_freebsd_m5p.com]

Move the setting line to isrc_alloc_irq(). This would allow keeping the interrupt number strictly on the event and removing it from intr_irqsrc.

I haven't yet figured out whether sys/arm/mv/gpio.c needs adjustment. Interestingly that file includes workarounds rather similar to my alternative plans.

[ehem_freebsd_m5p.com]

Squash review, adding removal of ->isrc_irq. This is one reason why allocating the event earlier has value, ->ie_irq can then substitute everywhere. If reviewers want this split back off, that can be done.

[ehem_freebsd_m5p.com]

Splitting D40166 back up. While I like the second part, it is lower value. This would serve to make all architectures noticably more similar.

[ehem_freebsd_m5p.com]

sys/kern/subr_intr.c

509

I should note, this is wrong. The author was thinking conflict between "INTR_SOLO" and events, but this could also occur from a race to create the event. This is inappropriate to address as part of D40166, but I notice it is lurking.