Subject: Re: PPP in user-space or kernel? was Re: autoconfiguration question
To: None <jonathan@DSG.Stanford.EDU>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 05/26/1997 10:56:39
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.Maemail@example.com 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