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)
Wed, Jul 10, 3:15 AM
Unknown Object (File)
Wed, Jul 3, 11:02 PM
Unknown Object (File)
Sat, Jun 29, 1:56 AM
Unknown Object (File)
Tue, Jun 25, 8:21 AM
Unknown Object (File)
May 21 2024, 2:34 PM
Unknown Object (File)
May 8 2024, 4:40 AM
Unknown Object (File)
May 8 2024, 4:40 AM
Unknown Object (File)
May 8 2024, 4:38 AM

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 53452
Build 50343: 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.