Andrea Arcangeli (arcangeli@mbox.queen.it)
Sun, 30 Aug 1998 16:15:39 +0200 (CEST)
On Sun, 30 Aug 1998, Joerg Dorchain wrote:
>My preferred model is as follows: CPU starts irq handling, dispatcher
>calls handler chain, hardware driver looks if it has to do something,
This can be your preferred model but you are not writing Linux this way I
think.
>does it, and returns. This way the low-level driver could also call a
>supllied function of some higher level.
>
>Besides, when using modules, the scheme still fits: load the mid-level
>(parport.o), then the low-level (parport_XXXX.o) to register all known
>ports, and then the high-level (e.g. lp.o) to register devices that use
>the ports.
>
>BTW, I looked a bit at the structures and functions in parport_share.c I
>am no speciaiist in this, but it looks like this could be implemented
>without changing the function API to the high-level-drivers. Only minor
>changes in parport_share.c and the low-level-driver are neeed. (Still
>there aren't many).
>Of course, the easiness of something isn't an argument wether it is a
>"right thing".
Supposing we implement this change to allow the parport lowlevel driver to
register a parport_pc_irq_handler() generic callback (that will recall
port->cad->irq_handler(...)) that the parport high level driver will
register as the port irq; are you going to hack every other device driver
out there to support plugin Amiga card? Or are you lucky and the only
plugin Amiga card are parallel ports ;-)? And now think why you like to do
the ack in the parport_m68k_irq_handler() instead of in lp_interrupt() and
plip_interrupt(), beacuse it' s more clean. So why not to do the ack in
the arch specific code?
Andrea[s] Arcangeli
-- To unsubscribe, send mail to: linux-parport-request@torque.net --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:09 EST