* David Brownell <david-b@xxxxxxxxxxx> wrote:
> On Monday 02 March 2009, Peter Zijlstra wrote:
> > On Mon, 2009-03-02 at 14:10 -0800, David Brownell wrote:
> >
> > > What's unfortunate is that you prefer not to fix that
> > > IRQF_DISABLED bug in lockdep, which you co-"maintain".
> > > When running with lockdep, that bug (a) introduces bugs
> > > in some drivers and (b) hides bugs in others. You've
> > > rejected even a minimal warning fix, to help minimize
> > > the amount of time developers waste on (a) and (b).
> >
> > I've come to the conclusion that the only technically sound solution is
> > to do as I proposed today, utterly eliminate !IRQF_DISABLED handlers.
>
> As you announced today. If you truly believe that, then
> you should at least submit a warning patch for 2.6.29-rc
> ("driver X isn't setting IRQF_DISABLED, reimplement!")
i have changed the BUG_ON() to a WARN_ONCE() message so the
warning is in place now.
> with a Documentation/feature-removal-schedule.txt plan for
> removing that mechanism. [...]
you are misunderstanding the workings and purpose of
feature-removal-schedule.txt. It is mainly used for
functionality that is user-visible. It is sometimes used for
functionality that a subsystem has exported to a lot of drivers
consciously and which is being removed.
It is never used for a single driver finding a core kernel
symbol and abusing it in a way that was never intended. Abuse of
kernel internals by kernel code was never a 'feature'. Just
because you find a symbol (which is not even exported to
drivers) does not mean you can use it like that.
If you want to work on genirq threaded IRQ handlers them please
check out and test the threaded IRQ handlers patches that are
being worked on at lkml. See:
[patch 0/4] genirq: add infrastructure for threaded interrupt handlers V2
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-input" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
