Messages in this thread | | | Date | Sun, 9 May 1999 22:45:41 +0100 (GMT) | From | Tim Waugh <> | Subject | Re: tunelp - was: Re: Maintainers |
| |
On Sun, 9 May 1999 Andries.Brouwer@cwi.nl wrote:
> So far the immediate fix. (If it is applied then a corresponding > comment should be added to the 2.2.8 lp.h so that nobody will take > 0x0610 later.)
Yes. Changing LPSTRICT's ioctl number looks to be the right thing to do.
> The first question is: this 2.0.35 behaviour - is it strictly according > to the specs? Not according to my notes, which say:
There are all different ways of doing this. The six common variations are:
busy-while-strobe and ack-in-busy busy-after-strobe ack-after-busy ack-while-busy
The 'correct' variation according to IEEE is 'busy-while-strobe and ack-in-busy'. The Centronics standard, on the other hand, is 'busy-after-strobe and ack-after-busy'. It's a can of worms.
Plus, no implementation should really care about this sort of thing, because it should be handshaking with ack rather than busy. It's on my to-do list, and the Linux implementation can potentially lose data with very slow hardware. ISTR some parallel port chipsets do the same thing though.
> In the 2.0.36 code I do not see any waiting for a definite period > of time - just strange loops like > wait = 1000; > while(wait) wait--; > with an execution time very much dependent on processor and alignment.
This isn't wrong as such: the wait time is defined to be in processor cycles. The bug is that wait isn't volatile (is that still true in 2.0.37pre?), although I don't think it actually causes any problems yet.
Tim. */
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |