>> i don't believe that compression should be in the kernel at
>> all (except, _maybe_ for the decompressor part, maybe).  too
>> many things get thrown in the kernel that, IMO, should be in
>> userland.  unfortunately, our current ppp implimentation
>> makes this really hard.
>
>The FreeBSD ppp implementation is all in user-land.  is there a good
>techinical reason why this couldn't be ported to NetBSD and used as
>the standard PPP on NetBSD.  I used it for a couple of months when
>I was running FreeBSD at home and it worked fairly well for me (although
>I have a fairly low traffic link, so maybe there are performance 
>problems that I am not aware of).

Is this the iij ppp implementation?

I have heard a lot of complaints about it on the FreeBSD mailing lists.
Basically, they boil down to the following things (if any of them are
wrong, please correct them)

- The documentation is mostly in Japanese

- Minus compression, it has poorer performance than the in-kernel ppp

- It tends to be buggy (but there are several workarounds for common
  problems)

- The code is a mess

I believe FreeBSD ships with both the userland version (iij ppp) and the
kernel version because of stability problems with iij ppp.  The cool
thing about iij ppp was that it supports Predictor-1 compression (thus
higher performance if the other side supports it) and it supports
demand dial.  However, our kernel ppp now supports demand dialing (I use
it every day), so the only advantage to it would be Predictor-1.

Personally, I'd rather see Predictor-1 go into the kernel ppp rather than
importing iij ppp.

--Ken