Stephen.Ma+netbsd-tech-kern@jtec.com.au writs:

>>>>> "Jason" == Jason Thorpe <thorpej@nas.nasa.gov> writes:

Jason> What benefit does moving it all out into userland give you?  I
Jason> seem to recall that at one point the argument was
Jason> "demand-dial", but seeing as how we handle that even with a
Jason> mostly in-kernel PPP, that argument doesn't wash with me...

>The main reason for moving this stuff into user-land is that PPP is
>getting somewhat bloaty (there are 7 compression methods already
>published as RFCs, plus layer 2 tunneling, plus multilink, plus
>encryption, plus LQM - all of these would need code in the kernel for
>a mostly kernel mode implementation).

So make the compression methods LKMs, and let the sysadim load them.
Show willingness to negotiate a methoid via the PPP control only if
the compression method is loaded.

(If we had a user-spae dameon to process callouts for dynamic loading,
then PPP could even ask for the compression modules to be loaded.)

Leave the rest of the PPP packet-forwarding (Tx and RX) code in the kernel.

User-space PPP may be adequate for an at-home connection to a single
host with a single PPP connection, but it's not adequate in general.

Going through TUN to user-space for a 45Mbit T3 link just doesn't give
acceptable performance.  If you have several 1.5 Mbit DS1 (or E1)
links, then going through TUN to user-space is no fun either.  One
person has already mentioned an `ISDN concentrator' with several
distinct PPP sessions each running over a single (or pair) of B channels.

I'm not even going to __mention__ PPP over SONET. :)

PS: this has at least as much relevance to tech-net as tech-kern...