Subject: Re: autoconfiguration question
To: Ignatios Souvatzis <ignatios@cs.uni-bonn.de>
From: None <Stephen.Ma+netbsd-tech-kern@jtec.com.au>
List: tech-kern
Date: 05/23/1997 20:27:01
>>>>> "Ignatios" == Ignatios Souvatzis <ignatios@cs.uni-bonn.de> writes:
Jason> ...err, why? If you just handle HDLC in zstty, then you can
Jason> use any line discipline ith it, yes? Then localtalk is a line
Jason> discipline like ppp...
Ignatios> Don't think so. HDLC is packet-oriented stuff.
Ignatios> You can implement the lower half of HDLC as:
Ignatios> - sync HDLC, which is done by special hardware, or
Ignatios> - async HDLC, which can be implemented (if you insist) as a
Ignatios> line discipline on a async serial terminal.
Ignatios> The real solution would be, to have some stackable interface
Ignatios> which at least CAN signal packet boundaries (for normal tty
Ignatios> applications, they would just be ignored).
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.
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).
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.
- S