lkml.org 
[lkml]   [1999]   [May]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.063 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site