[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arch
Subject:    Interrupts, Interrupted, Part I
From:       Elliott Mitchell <ehem+freebsd () m5p ! com>
Date:       2022-11-28 20:25:55
Message-ID: Y4UZUw+TiKudtrq2 () mattapan ! m5p ! com
[Download RAW message or body]

For interrupting devices, interrupts on FreeBSD are fine.  The bus
interface provides a reasonable mechanism for allocating a device's
interrupts.  A large number of devices work fine without extensions so
this appears reasonable.

For interrupt controllers the situation is a horror.  The x86 PIC
interface has greatly evolved since the mid-1990s, but portions make it
clear just how old the interface is.  Interrupts on PowerPC work
sufficiently differently that PowerPC has a similar, but not identical
interface which doesn't share any source code with x86.
When ARM was brought to FreeBSD, it had different issues with the
interface.  As such "INTRNG" is a third interface which shares no source
code and is quite different from the other two.


One of the first issues to resolve is the distinct naming of the headers.
Both PowerPC and x86 have their headers as <machine/intr_machdep.h>.
Since INTRNG was envisioned as being platform-independent (does manage to
cover both ARM and RISC-V, at least one MIPS device used it) its headers
are named <machine/intr.h>.  This seems to mark the aspirations of the
interfaces.  Unfortunately this makes compatibility worse as you need a
differently named header in one case.

I think one of these names needs to be chosen as the standard and have
everyone move to it.  Being in "machine/" already marks the headers as
potentially being incompatible, so I suggest <machine/intr.h> is the
better option.  Could D35559 collect some opinions and then maybe this
can progress?


Even if the interrupt interfaces are rather distinct they *do* have quite
a number of common points.  All of them have a structure which serves to
wrap the "intr_event" structure.  As such I think it would be rather
handy for all the interrupt interfaces to have an "interrupt_t" type.
This makes common code which doesn't need to touch the internals easier.

All 3 interfaces include the functionality of resolving an interrupt
number to the associated structure.  Yet of the 3, only x86 has the
function "intr_lookup_source()" to provide that to the outside.  For a
machine-independent interface I'm inclined to think "intr_lookup()" is
better as not all architectures refer to the structure as "source".

From 9b33b154b531, the justification for having the interrupt number in
the intr_event structure is to allow MI source code to lookup interrupt
numbers.  Problem is, this lookup is a (slow) linear search whereas
2 of 3 architecture interfaces have an efficient lookup. The third could
implement hashing for efficient lookup.  Worse, this interface was
restricted to the event core, so it simply fails to be useful for
interrupt controllers.  Once there is an MI interface and MI type, this
becomes simple to use the existing heavily used interface.

As such there were detours, but D32504 looks like a good solution.  I
hope the changes make this acceptable.  Yet I still need reviews and then
a committer...


-- 
(\___(\___(\______          --=> 8-) EHM <=--          ______/)___/)___/)
 \BS (    |         ehem+sigmsg@m5p.com  PGP 87145445         |    )   /
  \_CS\   |  _____  -O #include <stddisclaimer.h> O-   _____  |   /  _/
8A19\___\_|_/58D2 7E3D DDF4 7BA6 <-PGP-> 41D1 B375 37D0 8714\_|_/___/5445



[prev in list] [next in list] [prev in thread] [next in thread]