lkml.org 
[lkml]   [1999]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [patch] drivers/net/plip.c
I know I'm coming in a bit late, but I'm just a few days from my
defence, so please bear with me :-) I only have two comment to the
this story:

> Russell did a messy work when he designed the protocol. We have 5
> incoming lines. One of them triggers interrupt. When we read from the port
> we get those lines in bits 7,5,4 and 3. Interrupt line is in bit 6.
> Russell <substitute your favourite expletive> decided to use bits 6,5,4
> and 3 for data and bit 7 for sync. Sheesh... Yes, sir, shuffling bits
> would be terrible. Except that we can create a table and use it instead of
> bitops. Yes, whole horrible 512 bytes.

That's not quite fair to Russell. His package drivers were (are?)
working under different constraint: DOS, and the 1989 state-of-the-art
PC :-) 512 bytes was an awful lot for a resident driver at the time.
But his reasons might have been different. In any case, the real
achivement important issue was proof of concept.

Btw, table lookup can be fairly expensive if it results in a cache
miss. I remain unconvinced of the inherent advantage of either
option.


> Sync-on-intr would be much nicer, but no such luck. And we can't
> change the protocol - compatibility hits and all such. We could
> implement the second protocol and that would be the Right Thing, but
> that's another story. </rant>

Sorry, but that's BS. We definitely can (and maybe should) change the
protocol. When we worked on 8-bit PLIP we had no such reservation.
As I've stated whenever possible, the situation for 8-bit PLIP has
changed dramatically with the advent of ECP+EPP ports. Motivated
hackers might be able to come up with something actually nice, in
contrast to PLIP which will never be able to work well (that's the
reason I lost interest).

While I'm at this, I believe that emulating an ethernet adapter bears
way to much overhead. It seems much more logical and efficient to use
the PPP protocal over the parallel wire. After all, PLIP is all about
a point-to-point protocol. It might even make the driver simpler,
making it behave just like a supercharged serial port.

Keep up the good work Alexander!

Just my 0,05 Euro,
Tommy

-
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:50    [W:0.066 / U:0.556 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site