Tim Waugh (tim@cyberelk.demon.co.uk)
Fri, 25 Sep 1998 00:36:52 +0100 (BST)
On Fri, 25 Sep 1998, David Campbell wrote:
> Urk! Sounds like this driver needs to be made a lurker.
Actually, it just needs to support preemption, nowadays.
> b) imm_pb_claim() calls parport_claim(), should parport_claim() fail then
> a line of code puts the imm driver to sleep until the parport driver
> frees the parport and does a call back to wake the driver.
This could be done with parport_claim_or_block, which might be better.
> > Don't misunderstand me here: Your handling of the parport is correct if
> > your assumptions about the attached devices are correct. But within
> > imm_detect() you cannot be sure of the bus topology, thats why it's
> > broken.
>
> Huh?? parport was once called parbus, that is why there is imm_pb_claim()
> Phil & Tim, I think I need a little help explaining the parport concept here...
As you say, it was once called parbus, because it is bus-like. Think of a
broadcast medium like Ethernet, where once person has control of it at a
time.
Tim.
*/
-- 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:22 EST