Re: [PARPORT] Re: L68K: Amiga-Parport-driver

Andrea Arcangeli (
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

>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: --
-- 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