From: Felix D. <tm...@el...> - 2004-01-25 18:44:11
|
(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 |