Greg KH <greg@kroah.com> wrote:
quoted text
> > Our main concern is that this driver would be rejected by the kernel
> > maintainers, due to the fact that it busy-waits with interrupts
> > disabled, for up to 32ms (in the very worst and unlikely case).
>
> Why does it do this?

For precise timing purposes when polling the parallel port.  (Forgive
the alliteration.)

For example, a talking device will pull CLK down for 20us and release
it, after which DATA must be read within 70us.  Or, when sending a byte,
after the listener has released DATA, transmission must start within
200us.  (Notice how we don't always monitor the same line.)

In such cases, if an interrupt were to be triggered and take too much
time, the whole communication would be garbled.

(There is one case, when a listener is signaling that it is ready, which
has no upper bound and does not require prompt action.  That's when we
use the parport IRQ.)


BTW, I should point out that the 32ms above is the absolute worst case,
and would require a device to maliciously skirt on the maximum timing
allowances of this module.  I'm guessing 1-2ms is the likely case.)


quoted text
> > rs_put_char() in drivers/serial/68328serial.c.)  Unfortunately, this is
> > the only way to achieve the precise timing required.
>
> Are you sure?

You tell me, you're the kernel demi-God.  :)

Basically, this module needs a guaranteed sub-20us resolution when
polling the parallel port for inbound data.  (The PC parport
unfortunately only has one line capable of triggering an IRQ, which is
already used for the case above.)  And it may need an even greater
resolution when sending data, as other devices may not be so forgiving
of timing errors.


-- 
[FORTRAN] will persist for some time -- probably for at least the next decade.
		-- T. Cheatham

_______________________________________________
Kernel-mentors mailing list
Kernel-mentors@selenic.com
http://selenic.com/mailman/listinfo/kernel-mentors