Re: [PARPORT] interrupt-driven lp

Andrea Arcangeli (
Fri, 2 Jan 1998 16:04:35 +0100 (CET)

On Fri, 2 Jan 1998, Philip Blundell wrote:

>>If you want to take backward compatibility you must don' t take any notice
>>about others __waiters__ devices. This was why ppa (not a waiter
>>pardevice) remains locked at first (waiting for a lp_parport_release).
>The correct fix, which I tried to put into parport-980101 though I've no idea
>if it works (early indications are that something is still wrong) is to make
>the waiters variable count other devices as well. Please take a look.

You added also the CVS directory.

Yes seems a good change. I merging my patch with your 980101.

>>I think this is the best and efficient way to handle the parport_yield.
>>For example in lp when we run lp_schedule we __must__ schedule() at least
>>one time and not only parport_claim_or_block(). We check for need_resched
>Indeed. That's why parport_claim_or_block() returns a value saying whether or
>not it slept. If it didn't, you may need to call schedule() yourself.

No, _explicit_ schedule() _is_needed_.

- ppa claim
- ppa release, claim the port for lp and wakeup the lp waiter
- now the printer goes offline for an external event
- lp run lp_error()
- lp_error() run lp_schedule() that should sleep for LP_TIMEOUT_POLLED
  jiffies with the port _released_
- lp_schedule exec parport_yield()
- parport_yield (consider the case that it don' t take care if there are
  waiters that are waiting for a wakeup) release the port, wakeup ppa that
  will claim the port and lp goes to sleep (it should sleep with the port
  _released_ for LP_TIMEOUT_POLLED)
- ppa run its ppa_engine()
- ppa release the port before LP_TIMEOUT_POLLED jiffies and so claim the
  port for lp (that is a waiter and isn' t sleeping in schedule()) so
  wakeup lp ___before___ LP_TIMEOUT_POLLED
- lp run again and the port is again off-line....

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