Page MenuHomeFreeBSD

Working on commonizing standard interrupt functionality
Needs ReviewPublic

Authored by ehem_freebsd_m5p.com on Mar 20 2023, 11:15 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Mar 28, 8:13 AM
Unknown Object (File)
Feb 20 2024, 12:04 PM
Unknown Object (File)
Jan 21 2024, 4:03 PM
Unknown Object (File)
Dec 20 2023, 4:04 AM
Unknown Object (File)
Dec 18 2023, 10:46 AM
Unknown Object (File)
Dec 10 2023, 3:51 PM
Unknown Object (File)
Dec 4 2023, 12:42 PM
Unknown Object (File)
Nov 11 2023, 1:25 PM

Details

Reviewers
jhb
manu
andrew
Summary

Identifying some functionality all architectures have and trying to
make a common interface.

Squash review:
intrcompat: add "interrupt_t" typedef for all architectures

For code which doesn't care about the underlying structure and simply
needs to have a common name.

intrng: add standard interrupt controller interface

Interrupt numbering belongs to the interrupt controller, not the core
event code. As such, this layer should be providing a function to
resolve the interrupt number to the source/event.

powerpc: add ability to access intr_event by interrupt number

Most other systems have this via INTRNG or other means. Now add the
functionality to PowerPC.

intr/x86: implement standard interrupt interface

Different name for the main function, but then a simple macro on top.

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 50489
Build 47380: arc lint + arc unit

Event Timeline

The reasoning behind intrtab_lookup() is it should be possible to break the interrupt table functionality out of the interrupt cores. I've got some rough ideas of what such would look like, the difficulty is PowerPC being so different from everything else.

One concern I've got. What is the range of supported compilers? I believe some older compilers won't accept typedef struct foo type_t; as an incomplete declaration of struct foo. Those would need separate incomplete declarations, but I'm unsure whether those are included in the support window for this.

Tiny adjustment, split the NULL-check to a separate step. Just in case a use does the NULL-check itself and simply wants the appropriate field name. Hopefully common-subexpression elimination would take care of this, but it might not.