I meant what I meant was that nothing should stop us from added a
different protocol. The name could even be changed if that's an issue.
A DMA capable, 8 bit PLIP-like would be much nicer, but the lack of a
standard cable might be a show stopper.
....
> The overhead on plip being ethernet compatible is basically nil. Its probably
> lower than PPP once you've considered alignment and header decode issues.
Ok, I stand corrected.
Alexander Viro wrote:
> 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>
Interrupt for each byte? ~50 kHz interrupts would require a pretty
low latency, or am I missing your point?
> 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.
Definitely negotiation/autodetection.
/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/