> 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.
<nitpick> we ignore low 3 bits, so it can be turned into 256 (erm, 260)
bytes if we allow AND and 64 bytes if we allow SAR (used anyway).
> Btw, table lookup can be fairly expensive if it results in a cache
> miss. I remain unconvinced of the inherent advantage of either
> option.
On 286??? Anyway, 32+32 (we use only one direction each time) is
not too terrible. Moreover, it follows busy waiting with lots of port
accesses.
</nitpick>
> > 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).
Erm... IIRC PLIP used in 1.0 was canned exactly because of
incompatibility with original protocol. Maybe we should follow 386BSD here
and allow several protocols selected by ioctl() (from ifconfig). Maybe we
might even add negotiation there.
> 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
PPP has its own overhead. BTW, do we really want non-IP traffic
over parallel line?
> a point-to-point protocol. It might even make the driver simpler,
> making it behave just like a supercharged serial port.
Hrm... PLIP becoming a line discipline... Interesting. It doesn't
fit too well into this scheme - we can't do transfers in both directions
simultaneously.
-
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/