Date: Wed, 10 Jan 1996 11:00:17 -0700 From: Nate Williams <nate@rocky.sri.MT.net> To: dennis@etinc.com (dennis) Cc: hackers@freebsd.org Subject: Re: pppd vs ijppp Message-ID: <199601101800.LAA18199@rocky.sri.MT.net> In-Reply-To: <199601101744.MAA24543@etinc.com> References: <199601101744.MAA24543@etinc.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[ 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199601101800.LAA18199>