Roger Schreiter (Roger.Schreiter@Spectro21.de)
Fri, 24 Sep 1999 13:20:40 +0200
> Ah, caught me. I hadn't thought of parport_negotiate. We _could_
> the approach that negotiation doesn't happen very often anyway, and
> it as it is, but..
Even if negotiation doesn't take place very often, it occours.
E.g. for SPP hardware each time when reverse communication is
I suggest to introduce the non-blocking-feature also for the
negotiation funcs. (Same way as proposed in Tims draft
for write and read funcs.)
> Up to 150ms in a bottom half? I think that will have an unacceptable
> on things like networking and the serial driver.
And what about 35msec? (This long wuold parport_wait_peripheral
take in case of a timeout when the parport-timeout-value is set to "0".)
I think it's also too long.
That's why I would like to introduce another flag which tells
parport_wait_peripheral to give up earlier (to be called once
again later for the same state). Maybe we could take "negative
timeout values", which would tell parport_wait_peripheral to
wait in any case no longer that the negative of that amount
(and of course not to call schedule).
> be organised as a kernel thread that gets woken rather than a bottom
Yes, that would be a totally different solution for our problem.
But as our code for IEEE1284.4 is almost ready using bottom halfs,
this is not our favourite solution.
(To be honest, I don't know very much about kernel threads. Just,
that they exist now and that they are the "equivalent to the &-sign
after a shell-command" (roughly spoken) for kernel code.)
If an kernel expert would convince us, that we should change all our
to use kernel threads (because they are indeed the m u c h better
technic?), we would of course consider doing it.
What do you think about finding a way, telling parport_wait_peripheral
to abort ealier, as I explained above?
-- To unsubscribe, send mail to: firstname.lastname@example.org --
-- with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Fri 24 Sep 1999 - 07:14:29 EDT