[comments on how hdlc bit-sync is different from async]

> I suspect that's what Jason's trying to imply - the zs device still
> acts as a "tty" device, passing data thru the terminal handler. We add
> a new line discipline "sync HDLC", which passes (or merely preserves)
> packet boundary information between the device driver and the user
> system call.

Which "zs" driver? port-mac68k is moving towards using the M.I. serial
driver (we use an old, custom version of it at the moment and I'm
ppp'ing from a mac using the new driver).

With the new driver setup, there's a zsc, which represents the chip,
and there are slaves, like zstty and the sun3 mouse & keyboard, which
personalize the port for a certain use. Given this framework, the
easiet thing to do is make another slave, zshdlc, and let zstty and
zshdlc take turns at using the hardware.

> One side-effect of all of this would be that it'd be easier to make
> all the async PPP code do sync PPP talking through appropriate devices
> such as the zs (which is something I'd very much like to see).

Letting the hdlc stuff do syncronous PPP is one reason I want to make a
different device. Adding a sync PPP and a LocalTalk (and an X.25?)
line discipline would be very gross. If we just have a different
device, which supports its own line disciplines (PPP, LocalTalk,
Raw), it's all cleaner.

Specifically, if_ppp would talk to a different ppp interface than that
in ppp_tty.c.

What toerh hardware can do both async and bit-syncronous PPP?

> While on this topic, the current tty code uses clist structures to
> queue up information. The 4.3BSD daemon book mentioned that these
> structures may be replaced by mbufs sometime, but this hasn't
> happened, and in the meantime, that plan has disappeared from the
> 4.4BSD daemon book (the authors refer to the large effort involved in
> changing both the tty code and all of the affected device drivers).
> 
> It seems to be that this change would still be a logical thing to do,
> since there would be one less kernel buffer structure to manage, and
> data could be passed between tty devices and networking stacks without
> copying.

That's well beyond what I want to get into at this point!

Take care,

Bill