Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:

   On Sun, 25 May 1997 15:50:23 -0700, Jason Thorpe writes:

   >On Mon, 26 May 1997 08:32:05 +1000 (EST) 
   > Stephen.Ma+netbsd-tech-kern@jtec.com.au wrote:
   >
   > > The main reason for moving this stuff into user-land is that PPP is
   > > getting somewhat bloaty

   >...this is a good argument for proper modularization, the ability to
   >compile in support for only that which you want/need, and for a sane
   >LKM interface... but I still think the cost of copying the data around
   >is too high in practice.

   The context switches (or latency, if you batch packets) can be painful
   too.  Otherwise, yup. We really have to stop thinking of PPP as used
   only on low-bandwidth links.  (And for some of the machines NetBSD is
   used on, the threshold for ``low bandwidth'' is _very_ low, too).

   I'd be OK with moving PPP link-level state control and per-protocol
   control into userspace.  (If the link is up and not changing state,

use the source, Lu^H^HJonathan, and Jason, and whoever started the
thread. It's already done this way.  The ppp line discipline handles
the registered protocols in-kernel, passing them to the appropriate
network input handlers, and makes all the others available to be
read(2) by a priviledged user process.

The only stuff you need in-kernel (or lkm'd, eventually) are the
compression protocols and the data transfer protocols used (but only
data compression part, not the negotiation part/state machine).

And pppd should very well be able to load KM's, if the kernel is
operating in unsafe mode.

A proper streams implementation would help modularize this in an
easier way (e.g. put the ppp module on top of (sync HDLC on top of (zs
serial or ISDN) or async HDLC on top of (serial tty or V.110 on top of
ISDN))), maybe.

Regards,
	Ignatios