HEADS UP: interrupt filtering & newbus API breakage

Hi developers,

after re@ approval, i'm ready to commit my first interrupt filtering
patch that contains _JUST_ the modification to the newbus API: no new
features, no improvement to the interrupt handling, etcetc

The patches against a 4 weeks old HEAD are here:

http://people.freebsd.org/~piso/intr_filter/

where:

* intr_filter-newbus-MI.patch contains the diffs against the MI code

* intr_filter-newbus-$ARCH.patch contains the diffs against the MD
code for the various $ARCHs

* intr_filter-newbus-full.patch contains all the diffs in one big
patch file

For every patch file, there's a $patch.files, containing the list
of files modified by that patch.

Moreover, i put there a tarball of my src/sys dir (sys-intr.tgz) just
in case the big patch doesn't apply correctly.

In details these patches do:

-change bus_setup_intr() syntax (and the functions strictly connected
to it), adding a new filter_t argument -> this modification affects
all the drivers in our tree, and is the main source of
'fatness' of this patch

-retire INTR_FAST/IH_FAST (with the above modification to the syntax of
bus_setup_intr() these flags were redundant and senseless)

-change the FAST handlers to return a value (interrupt handled/interrupt
not handled/etcetc)

Unfortunately the patch is big (170kb), but the modifications were
mainly mechanical and i pushed different developers to test/review
my code.

I run these patches on i386 & amd64 for quite a bit, and all
the other archs (but sun4v) were tested with this code, and showed
no ill effects.

With this patch in place, all the remainig work about interrupt filtering
can be commited and wrapped in #ifdef ... #endif without affecting the
normal interrupt handler.
Moreover, with this "noise" out of my dvelopment branch, the rest of
the work (aka the new interrupt handling mechanism) could be easily
reviewed by different people.

So, if none as anything against it, i'm going to commit this work on
Friday 23 around 14:00 UTC, so speak now or forever hold your peace.

bye,
P.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages

  • HEADS UP: interrupt filtering & newbus API breakage
    ... patch that contains _JUST_ the modification to the newbus API: ... features, no improvement to the interrupt handling, etcetc ... -change the FAST handlers to return a value (interrupt handled/interrupt ... So, if none as anything against it, i'm going to commit this work on ...
    (freebsd-current)
  • [PATCH] drivers/serial/sunzilog: Interrupt enable before ISR handler installed
    ... I have added a from line, comment and signed-off-by line to the attached patch file. ... The attached patch changes the interrupt enable sequence for the sunzilog ... handler has been installed. ... switch (cflag & CSIZE) { ...
    (Linux-Kernel)
  • Re: [PATCH]: Atmel Serial Console interrupt handler splitup
    ... So, to come to a conclusion about this complex patch series, I ... yesterday including inline are also included to make the set complete. ... this is the order in which the patches should be installed: ... + * receive interrupt handler. ...
    (Linux-Kernel)
  • Re: [PATCH]: Atmel Serial Console interrupt handler splitup
    ... Not really architecture independant, I believe, because thos are ... begone" patch which was merged into mainline a few weeks ago. ... had to make the driver pass the scripts/checkpatch.pl check, ... into a interrupt top-half and some tasklets. ...
    (Linux-Kernel)
  • Re: [patch 00/21] 2.6.19-stable review
    ... Bug reports: ... Even if we just put in my tiny fix that allows us to generally ... The first patch is obvious, but of course that isn't the interesting ... irqs disabled during all of the interrupt routines). ...
    (Linux-Kernel)