Tim Waugh (tim@cyberelk.demon.co.uk)
Sun, 19 Sep 1999 17:56:50 +0100 (GMT)
On Fri, 17 Sep 1999, Roger Schreiter wrote:
> > which would normally busy-wait for 35ms quite often, would just have to
> > change the register_device 'flags' parameter from 0 to
> > 'PARPORT_FLAG_USE_MICROSTEPS' and busy-waiting would almost disappear.
>
> ... so only the read or write funcs may return when the device is slow?
Ah, caught me. I hadn't thought of parport_negotiate. We _could_ take
the approach that negotiation doesn't happen very often anyway, and leave
it as it is, but..
> A timer interrupt awakes a socket. The socket looks, whether there are
[For those in the audience unfamiliar with IEEE 1284.4, I think Roger is
talking about MLC sockets here. Basically, IEEE 1284.4 provides multiple
logical channels of communication, and so a sockets interface can be built
onto it.]
> parport data available or wether the pardevice is again able to receive
> data. When there is something to do, it activates a bottom half
> (BH_IMMEDIATELY) for a function is called as soon as possible,
> which will carry out the work. And that function may consume ap
> to 0.15 s before returning (as extreme case). Will that be tolerable?
I don't know. Would some kernel hacker like to comment? It isn't very
_nice_, but I think it's tolerable. Basically, no-one else's
non-immediate bottom halves will get run, so it's probably bad news.
If parport_negotiate is broken down into microsteps, I can imagine some
code that tries to negotiate, realises that it hasn't completed, and marks
a bottom half to try again a bit later. That would be a lot friendlier.
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 Sun 19 Sep 1999 - 13:21:54 EDT