On Fri, 7 May 1999, Andrew Doran wrote:

> [Cc:'d to tech-net because I think it's worth discussion].
> 
> "Perry E. Metzger" wrote:
> > 
> > Andrew Doran <ad@fionn.sports.gov.uk> writes:
> > > "Perry E. Metzger" wrote:
> > > > Andy Doran <ad@fionn.sports.gov.uk> writes:
> > > > >       Porting & testing FreeBSD/OpenBSD userland ppp(8) (nearly done)
> > > >
> > > > Why the hell would we want that?
> > >
> > > Because it's far better than in-kernel ppp, both performance and
> > > feature wise.
> > 
> > 1) I can't believe the performance bit at all. Userland PPP *cannot
> > possibly* keep up with doing ppp at many megabits per second. Yes, we
> 
> You misunderstand. I'm not talking about many megabits per sec, I'm
> talking
> about small devices, although point taken.

If you're not talking high rate, how is it beter performance?

> > have drivers and software for T1 cards now.
> > 2) If we are lacking features, we should work on those. PPP belongs in
> > the kernel, though, just like the ethernet drivers and everything
> > else...
> 
> From the ppp(8) manpage below. Yes, probably not a good idea for leased
> line 
> operation, but for operation over analogue/PSTN devices, ppp(8) is great
> (I 
> regularly see 5-30, sometimes 90k *bytes*/sec over 33.6 modem w/ppp(8)).
> Can 
> we not provide both, and let users decide? ppp(8) has a different
> feature-domain 
> than pppd(8).

I really don't understand this. Our current solution, w/ pppd, is a
combination of userland & kernel. As I understand it, userland handles the
setup of the connection, then hands things off to the kernel when ppp's
up. So the kernel is only doing the part it does best, leaving the rest to
userland.

Most of the features listed in the man page we have (I think). Like CHAP &
PAP & demand dial. The ones we don't, we should add. 

Take care,

Bill