Page MenuHomeFreeBSD

intrng: convert to using resource manager for interrupt numbers
AbandonedPublic

Authored by ehem_freebsd_m5p.com on Jun 6 2022, 11:23 PM.
Tags
None
Referenced Files
Unknown Object (File)
Sat, May 4, 10:31 AM
Unknown Object (File)
Dec 20 2023, 4:31 AM
Unknown Object (File)
Dec 20 2023, 1:20 AM
Unknown Object (File)
Dec 18 2023, 11:59 PM
Unknown Object (File)
Jun 28 2023, 6:46 AM
Unknown Object (File)
May 6 2023, 9:36 AM
Unknown Object (File)
Feb 17 2023, 3:01 AM
Unknown Object (File)
Dec 31 2022, 12:38 PM

Details

Reviewers
manu
andrew
Summary

The kernel interrupt numbers do amount to a type of resource. As such
this is the forte of the resource manager code. This should open future
possibilities.

Diff Detail

Repository
rS FreeBSD src repository - subversion
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 45878
Build 42766: arc lint + arc unit

Event Timeline

For some interrupt controllers it makes sense to allocate a range of interrupt numbers, rather than allocating them individually every time an INTRNG source is allocated. Interrupt numbers for INTRNG look suspiciously like a resource, at which point placing them with the resource manager seems to make sense.

This is a WIP, I'm unsure of the implementation. Perhaps an interface needs to be proposed first.

Huh, looking back at this I'm wondering why the mv_ap806 bits were needed.

I'm pretty sure the approach is correct. I think my evaluation of value was wrong though, from what I've seen most ARM/ARM64/RISC-V interrupt controllers would substantially benefit from an approach like this. Right now most controllers are allocating large arrays of intr_irqsrc structures which effectively replicate the purpose of irq_source in subr_intr.c. Add the ability to allocate ranges and most controllers could individually allocate intr_irqsrc structures instead of needing a large array.

I think I've found a better way to address this. Alas tis a bunch of commits and the throughput for non-sponsored patches is atrocious.