> 
> On Tue, 20 May 1997 13:40:26 -0700 (PDT) 
>  wrstuden@loki.stanford.edu (Bill Studenmund) wrote:
> 
>  > You might be right, but I'd like to try to find something different.
>  > Hacking an hdlc mode into the zstty code just looks gross, though
>  > attaching a zshdlc to the zstty might work.
> 
> ...err, why?  If you just handle HDLC in zstty, then you can use
> any line discipline ith it, yes?  Then localtalk is a line discipline
> like ppp...

HDLC mode for this chip strikes me as a different beast than async
serial. In HDLC, the chip acts like a network node. It can send and receive
packets, complete with a begin-frame mark, the data, a CRC, and an
end-of-frame mark. It can be assigned an address, and told to ignore
non-broadcast packets for other frames. Basically, it's a network
interface.

If you got one of these chips which was fast enough, you could use it
(in hdlc mode) as the guts of a Token Ring interface.

As such, it really shouldn't use the tty queueing system. The tty
system was designed for data w/o message boundries. The interface will
need these boundries. The cleanest looking interface I've seen do far
is something like how the tun interface works. Each write is a packet.
Each read is a packet (if the buffer's big enough).

Given that, zswrite, zsread, and a lot of other routines would need to
check and see if we're in hdlc mode, and swith to other code if so.
Also, the interrupt routines would need to be different. Transmit needs
to deal with sending an end-of-frame, receive needs to deal with
end-of-frame stuff, and there are a few other status interrupts.

The zstty driver is a nice, clean tty driver. To cram a network interface
into it would look gross (in my opinion). Plus, all the folks who don't
care about hdlc modes have to deal with the changed code.

>  > Another things is that we run into a possable can of worms if HDLC
>  > support is a "mode" of the async driver. I think at open you need to
>  > indicate which way you want the hardware to behave. Thus avoiding
>  > problems like having a program talking to a modem, and then having
>  > another process start up and try to put the port in hdlc mode.
>  > So different device numbers and thus different open routines provide
>  > protection.
> 
> ...we don't special case for "dialer lines", so why for HDLC?  If processes
> want to avoid collision like that, they should be using TIOCEXCL.

Why special case? Because I don't think we've ever had a driver which turned
a serial port into a network interface; to something where the output data
are incompatable with normal RS-232 signals.

The LocalTalk daemon will certainly want exclusive access. But there's no
reason why one process could be writing in hdlc mode and another reading (also
in hdlc mode). The collisions I want to avoid aren't someone vs. LocalTalk,
but async vs. HDLC framing.

If all I wanted to do was add LocalTalk, then a line discipline'd be ok (as no
data would ever go through the tty system). But I'd like to also support
ppp w/ bit-sync hdlc, and (for debugging & general use) just firing frames
in and out of the poirt. A seperate device type to handle hdlc activity
just seems the cleanest to me. Not the only way, but the cleanest.

Take care,

Bill