Page MenuHomeFreeBSD

intrng: expose lower-level device interface for INTRNG
Needs RevisionPublic

Authored by on Mar 29 2023, 7:33 PM.
Referenced Files
Unknown Object (File)
Wed, Aug 30, 2:48 AM
Unknown Object (File)
Aug 14 2023, 11:06 AM
Unknown Object (File)
Jun 19 2023, 8:10 PM
Unknown Object (File)
Jun 19 2023, 3:15 AM
Unknown Object (File)
Jun 3 2023, 5:09 PM
Unknown Object (File)
May 15 2023, 5:41 AM
Unknown Object (File)
May 3 2023, 6:31 PM


Group Reviewers
Core Team

Specialized peripheral PIC drivers may need to handle most interrupt
setup steps themselves without touching newbus. Two cases are
intr_add_handler() and intr_describe() which are internally used by
intr_setup_irq()/intr_describe_irq(). Exposing these allow for
alternative use case.

In fact the BUS interface for INTRNG is arguably a layering violation.
Those 6 functions could just as well be in nexus.c or a kernel library.

Diff Detail

rG FreeBSD src repository
Lint Passed
No Test Coverage
Build Status
Buildable 50668
Build 47559: arc lint + arc unit

Event Timeline

Any suggestions for reviewers?


Hopefully the reasoning for argument order change is obvious, this is to move closer to matching x86's intr_add_handler() function (doesn't yet match precisely).

mmel requested changes to this revision.May 9 2023, 4:56 AM
mmel added a subscriber: mmel.

I strongly disagree, it's a clear step backwards. Intrng was designed with strong layer separation and you are trying to break it in a similar way to x86.
The consumer interface for interrupts is in the kern_intr.c file and no one else is allowed to use it. The provider interface is intr_isrc_*. All other functions should (and must) remain private or unpublished outside of intrng.

This revision now requires changes to proceed.May 9 2023, 4:56 AM

I am in fact taking inspiration from x86 since the general idea was to fully split the layers apart (move the outermost functions to perhaps sys/kern/subr_nexus.c). Then it might also match x86's needs and push architectures closer together. In particular, D35559 plus D39178 greatly help with merging.

Unfortunately this really isn't a single-person task and needs more guidance to achieve (or perhaps the sluggish handling of patches for FreeBSD has worn me down).

Looks like sys/arm/mv/gpio.c has a situation similar to what I'm looking at. The approach of doing local calls to intr_event_create() has been tested and functions, but this seemed unlikely to be accepted by a reviewer. Yet this makes me the second person to run into troubles with INTRNG due to assumptions in its interface.