Subject: Re: autoconfiguration question
To: None <Stephen.Mafirstname.lastname@example.org>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
Date: 05/25/1997 15:55:17
>>>>> "Jason" == Jason Thorpe <email@example.com> 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...