In message <199705261803.UAA00500@rumolt.teuto.de>  Martin Husemann wrote:
> > ...as would I.  I would think that the sync PPP support could be added
> > to our PPP, and the changes be sent back to Paul.
> 
> Hmm - we ARE doing Sync PPP with NetBSD-current's pppd, it's just a tweaked
> Makefile and sys-bsd.c replaced by sys-isdn.c. - works great. Paul made
> some provisions (by splitting ppp_tty.c from if_ppp.c) to use the main
> ppp stack for something not a tty device, so sppp and ppp could share
> a lot of kernel code. I haven't looked at the FreeBSD implementation in
> detail, so I don't know if they make use of this.

As the one who initially made this hack, the basic probblem (and the reason
for the bisdnd -- pppd connection) is that there (was / is ) no sane way
of openeing a network device for reading. If we could bind a socket to 
an interface (BELOW any real network stack!!) (or fake a character device for 
it) we could avoid the communictation between the userland deamons.
It is only needed to relay the PPP controlpackts (which in async ppp continue
to be send/received through /dev/ttyxx) to the pppd daemon and to issue the 
ioctls for ppp state-changes.

> 
> Like always design is a tradeoff. We now have two (userland) daemons involved
> in a Sync PPP connection: the ISDN management daemon, which spawns pppd as
> soon as a connection is established or outbound packets pending. Both daemons
> have to communicate with each other and the kernel, both have to have
> matching  configurations. And there is a noticable penalty involved in firing
> up pppd with respect to connection establishement time. As soon as the
> connection is up and the used ppp protocols are up there is no difference
> between the pppd and the sppp approach.

There is NO NEED to port the kernel part of sppp, the problem stays the same. 
You still need a device to isuue ioctls on and the receive the control packets.
Sending data to userland is not an option (for reasons of overheadd and
latency, pointed out in this thread already), unless we get RT-threads ...

> 
> We will try to integrate parts of pppd into the ISDN management daemon, 
> hopefully by compiling the relevant modules from pppd into it. Maybe we'll
> end up with libppp.so.x.y?

I thought about that and dismissed it. It would make traking changes in pppd
to hard.

[ ... ]

Julian Elischer was/is working with the ATM group for some generic interface
for this kind of stuff (for use with framerelay and ATM hardware as far
as I know), mainly on FreeBSD.

Stefan

> 
> Martin

--
Stefan Grefen                                Tandem Computers Europe Inc.
grefen@hprc.tandem.com                       High Performance Research Center
If a group of N persons implements a COBOL compiler, there will be N-1
passes.  Someone in the group has to be the manager.
                -- T. Cheatham