LocalTalk tops out around 230Kb/s. In principle, you could do this in a
line discipline, IFF:

1. The line discipline is fast enough (for whatever value of "fast enough"
you need on the processor you're gonna run it on)

2. The rest of the kernel does not lock out interrupts so long that you
miss bytes.

The question is, at a given clock rate for a given processor, how many
instructions do you get to execute before you start losing bytes out of the
UART FIFO? The entire execution path for handling bytes off the serial I/F
must be smaller than that. This is the same class of problems as serial
PPP, except that the data rate is between four and five times faster.

My bet for the wide range of platforms that NetBSD runs on is that you will
have do to it:

1. In dedicated hardware that handles the individual bytes, and presents
whole DDP packets to the rest of the kernel.

2. in specially optimized P-DMA code that "knows" about DDP frames.

3. without interrupts on while fetching a frame off the serial I/F (same as
#2?).

Now, an Alpha or a high-end SPARC might do OK as is, but the rest of the
platforms that NetBSD runs on will have to be checked for long sections of
code where serial I/F interrupts are disabled, and those sections will have
to be (ideally) removed, or (at least!) minimized.

Bill has heard this litany from me before on port-mac68k...

One other observation: Dennie Ritchie originally did streams for 8th
Edition UNIX with the goal of replacing TTY line disciplines (his
observation was that despite the useful place that TTY line disciplines
occupy in the kernel, very few had been written, because they are a bitch
to write). I would argue that within that limited sphere (and specifically
*excluding* the egregious things that USG/USL did to streams to make it
into System V STREAMS (their "answer" to BSD sockets as an API for general
purpose networking)), streams were quite successful, and that we might do
well to consider the same development path.

	Erik Fair <fair@clock.org>