> From: wrstuden@loki.stanford.edu (Bill Studenmund)
> Date: Thu, 22 May 1997 17:54:39 -0700 (PDT)

> > 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.

Is the H/W so different in this mode that you are not likely to try to
plug in a plain-old async device?  One simple solution is to configure
a kernel that makes that line HDLC only.  (appletalk port?)

> 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.

I too would like to see the HDLC driver remain separate from zstty
as much as possible.  Maybe the zstty driver, or the MD "zsc" driver
could support "plugging in" a new zsops vector somehow.  That would
eliminate any need for "hdlc mode tests" in the zstty code.

Gordon