Howdy, everyone!

As part of the LocalTalk design, I've been snooping around in the
network source, and have some questions.

What are the packet reading & writing routines in
src/usr.sbin/pppd/sys-bsd.c for? It looks to me like our ppp keeps
packets in the kernel, so why are they going out? Or am I missing
something, and the packets really do cross the blood- brain barrier
twice?

There's a bunch of code in sys/netccit which claim to be the hdlc
support for X.25. I ask as I think adding an hdlc tty line discipline
is one step along the way of adding localtalk support. Does anything
actually use the X.25 code? It is pulled in with "options HDLC", but it
looks like it's more accuratly named "options X25". Also, NOTHING
outside of sys/netccit seemed to refer to it.  Would it be possable to
rename it "options X25" as it is definitely not the same thing as what
I envision (I'm talking hardware layer, it's the next level up or so)
and I'd like to reduce name confusion.

I am still trying to decide how exactly to deal with the tty when firing up
LocalTalk.  I'm not sure if it's better to have a seperate device, like
a zshdlc, which sits beside the zstty and has its own major device #
(and locking so you only access one at a time), or if it's better to
leave it a tty, and to impliment an hdlc line discipline. The reason for
the hesetancy is that in hdlc the hardware is in a vastly different mode,
and that I think the best approach to user-process communication (when
usable) is to blow off the tty subsystem, and handle reads and writes
more like how the tunnel interface works. So it's not really going to
look like a tty interface, other than it comes out the same plug in the
back of the computer.

One last question, eventually it'll be nice to add Appletalk tunnels. Would
it be better (preferable) to clone the tun interface into something like the
"atun" interface, or to let the tun interface accept AppleTalk address to.
Or for the tun interface to have a mechanism to specify which address
families it supports.

Take care, and thanks for reading these wonderings.

Bill