> 
> 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?)

If we're going to go the route of the-port-does-only-one, then I think
a run-time decision would be better. So many of the mac68k users can't
compile their own kernels, that adding an extra config choice would be
confusing. We already have two different scsi drivers, and a hand full
of kernels with custom video hacks. Multiplying it all by 2 to add hdlc
would make a big mess, I think.

Also, I don't like the system forcing boot-time decisions when we can
make the changes on the fly (and I thnk we can, here).

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

Changing the zsops (the interrupt service routines) is half of my
solution.  My idea was that the zstty driver'd hook up as normal. When
someone opened the zshdlc driver (and the zstty wasn't open), we'd set
a flag saying the child's in hdlc mode (keeping the zstty closed) and
swap the hdlc interrupt routines in for the zstty interrupt routines.
When the hdlc gets closed, we put the zstty routines back, and clear
the in-use flag.

Gordon, I'm sending you these changes, just so you can see what I'm
thinking of.

As the hdlc mode would use a different device, all the read & write
routines don't need to special case out hdlc.

Take care,

Bill