Hi Russell !
> That is incredibly wasteful for level interrupts - what you're suggesting
> means that to service a level interrupt, you take an interrupt exception,
> start processing it, take another interrupt exception, disable the source,
> return from that interrupt and continue to service it. No thanks.
Oh no, that's not what I mean... I've come to agree with having several
flow handlers and thus the level flow handler would mask & ack, then
handle, then unmask is it should be for a level interrupt... What I
meant is that disable_irq could do soft-disable in all cases like it
seems to happen right now in the ARM code but not in Thomas patch.
> I thought you were the one concerned about interrupt handling overhead
> (about the overhead introduced by function pointer calls.) but that
> idea _far_ outweighs function pointer overheads.
I think you misunderstood what I meant by soft-disable :) Basically
bring in more of what ARM does in disable_irq/enable_irq.
> Sigh, I'm not teaching you to suck eggs - I was trying to justify
> clearly _why_ we have these different "flow" handlers on ARM and why
> they are important by contrasting the differences between them.
Yup, and I've finally been convinced, and Thomas patch _does_ have
different flow handlers. However, it doesn't do soft-disable or
lazy-disable as your prefer for disable_irq which means that you'll
still lose edge irqs on ARM. There are 2 ways out:
make disable_irq/enable_irq go through a specific implementation by the
flow handler or just ... generically have disable_irq just mark the
interrupt as disabled in the descriptor, and only actually disable it if
it happens to occur while it was marked disabled (in which case it can
be marked "pending" and possibly re-triggered on enable_irq if the
controller doesn't latch). I even had an idea of how to avoid the
re-trigger on controllers that _do_ latch properly easily: by having
chip->unmask return wether it needs re-emitting or not.
> Obviously, I should've just ignored your email since you know everything
> already.
Bah, don't take it that way please ! I was making a joke ...
Cheers,
Ben.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
