Joerg Dorchain (dorchain@wirbel.com)
Sun, 30 Aug 1998 13:15:04 +0200 (MET DST)
> >Again this probably isn't a change for 2.2. I'm not quite sure where your
> >interrupt acknowledgement should fit in - probably in examine_irq() actually,
> >since the idea is that this function gets called to see if it's a parallel
> >port interrupt.
IMHO an examine_irq()-function isn't a good idea. What should it return?
1 if not yet called since the last irq happened?
There is hardware (the kind of hardware I'm working with) where the irq
status is cleared when reading it. Because you know know when a
high-level driver thinks it good to call examine_irq(), you would have to
make a soft copy of it, and a flag indicating that the copy is valid.
That would be about the same procudre in software that is implemented in
the hardware. IMHO this hassle is enough to go through one time.
My preferred model is as follows: CPU starts irq handling, dispatcher
calls handler chain, hardware driver looks if it has to do something,
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".
Joerg
-- 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