Subject: Re: autoconfiguration question
To: None <firstname.lastname@example.org>
From: Martin Husemann <email@example.com>
Date: 05/26/1997 20:03:45
> ...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.
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.
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?
There are some things that must be done in userlang (CHAP and PAP secrets,
for example) and some things that might be done in userland (initial protocol
negotiation et al.), but the border is not realy fixed. Avoiding kernel bloat
is a maxime shared by us all, I guess.