(Sorry for not having proper f'ups, is it possible to post to the
newsgroup (archive) instead of writing to the mailing list? i'd prefer
the newsgroup interface).
Anyway, as Mist said, i prefer the linearized view of IRQs, at least of
the EXI irqs.
Take a BBA driver as example. The BBA driver wants to handle the EXI2
EXTIRQ. With my model, this would just be a "request_irq", as every
linux driver would do it.
With the two-level-way, we would have to implement an exi_request_irq,
which is imho something that the original request_irq could handle fine.
As we can't hardcode interrupt handling (because it might be a modem or
a bba or anything), we would effectively dublicate a linux api. Why
should we do this?
For example, on x86, where you have a cascaded irq, they are linearized,
too. You don't have to handle irq 2 to see which hi irq you have to
handle. You simply hook the hi irq and everything is fine.
I think EXI handling is different to DVD handling. I certainly don't
want to linearize everything, only the EXI handling, since there are
multiple drivers attaching to different exi IRQs.
VI, DVD etc. will all be ONE driver, so we wouldn't have to implement an
API rather to hardcode the several sub-interrupts.
Felix
|