From owner-freebsd-hackers  Wed Jan 10 09:57:53 1996
Return-Path: owner-hackers
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id JAA20262
          for hackers-outgoing; Wed, 10 Jan 1996 09:57:53 -0800 (PST)
Received: from rocky.sri.MT.net (rocky.sri.MT.net [204.182.243.10])
          by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id JAA20246
          for <hackers@freebsd.org>; Wed, 10 Jan 1996 09:57:47 -0800 (PST)
Received: (from nate@localhost) by rocky.sri.MT.net (8.6.12/8.6.12) id LAA18199; Wed, 10 Jan 1996 11:00:17 -0700
Date: Wed, 10 Jan 1996 11:00:17 -0700
From: Nate Williams <nate@rocky.sri.MT.net>
Message-Id: <199601101800.LAA18199@rocky.sri.MT.net>
To: dennis@etinc.com (dennis)
Cc: hackers@freebsd.org
Subject: Re: pppd vs ijppp
In-Reply-To: <199601101744.MAA24543@etinc.com>
References: <199601101744.MAA24543@etinc.com>
Sender: owner-hackers@freebsd.org
Precedence: bulk

[ kernel PPP vs. user-land PPP ]
> >Bloating the kernel with the features of user-land ppp is not a good
> >thing.  Also, it's *very* easy to debug the user-land version where the
> >kernel version is *much* harder to debug.  No reboots necessary. ;)
> 
> This is ridiculous....memory is memory and you use more with a user
> level implementation than a kernel version. If your not using it its
> optioned out...so who cares? You arguably need just as much kernel
> code to provide the necessary informatoin to the user level code (if
> done properly) then if you did it in the kernel.

Do you have *any* idea what you are talking about?  As a user I *might*
not always running PPP, but if it's in the kernel I'm *always* taking
the memory hit for it if it's in the kernel.  As an extreme example of
this, let's stick X inside the kernel since most folks use it.  If they
don't, they can 'option it out'.  I'm sure it would be much faster in
the kernel.  Heck, why not /bin/sh as well?  It's *always* used by at
least one process.

> Improving kernel debugging is not difficult...we debug much more
> complicated things than ppp within the kernel space. The fact than
> pppd debugging is poor is not a good reason to adulterate the entire
> mechanism.

But the idea is to *remove* things from the kernel that make sense to
remove from the kernel.

> Good datacomm should focus on the 99% and not the 1%. Imagine if you
> moved ethernet processing to user space to improve debugging?

I doubt very much that 99.9% of the users notice the load difference
between user-land ppp and kernel ppp.

Downsides to adding the features to the kernel:
1) It's always in memory even if the user doesn't want it.
2) It's difficult to debug
3) It doesn't belong in the kernel since it's not a 'kernel' type of function.

Upsides:
1) It's faster.

Show me why your upsides is better than the downsides above?  Show me
that it negatively affects a significant # of users (not in your mind,
in their mind).


Nate