From owner-freebsd-hackers Wed Jan 10 15:36:55 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id PAA12837 for hackers-outgoing; Wed, 10 Jan 1996 15:36:55 -0800 (PST) Received: from ibp.ibp.fr (ibp.ibp.fr [132.227.60.30]) by freefall.freebsd.org (8.7.3/8.7.3) with ESMTP id PAA12826 for ; Wed, 10 Jan 1996 15:36:51 -0800 (PST) Received: from blaise.ibp.fr (blaise.ibp.fr [132.227.60.1]) by ibp.ibp.fr (8.6.12/jtpda-5.0) with ESMTP id AAA16620 ; Thu, 11 Jan 1996 00:36:48 +0100 Received: from (uucp@localhost) by blaise.ibp.fr (8.6.12/jtpda-5.0) with UUCP id AAA01467 ; Thu, 11 Jan 1996 00:36:42 +0100 Received: (pb@localhost) by fasterix.frmug.fr.net (8.6.11/fasterix-941011) id AAA26447; Thu, 11 Jan 1996 00:08:41 +0100 From: Pierre Beyssac Message-Id: <199601102308.AAA26447@fasterix.frmug.fr.net> Subject: Re: pppd vs ijppp To: dennis@etinc.com (dennis) Date: Thu, 11 Jan 1996 00:08:41 +0100 (MET) Cc: nate@rocky.sri.MT.net, hackers@freebsd.org In-Reply-To: <199601101744.MAA24543@etinc.com> from "dennis" at Jan 10, 96 12:44:12 pm X-Mailer: ELM [version 2.4 PL23] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-hackers@freebsd.org Precedence: bulk dennis writes: > ioctls were designed for setting options, and the options can still be > largely managed > in user space. Good data communications requires good reporting, and information > availability is substantially better and more efficient in the kernel, not > to mention the performance penalty of a user level implementation. A kernel is something that needs to be as simple, small and efficient/reliable as possible, that's why it generally contains only : 1) stuff that *can't* be elsewhere because of the architecture of the system. 2) stuff that would not be efficient enough in user space. PPP basically needs to (A) emit/receive network (IP or other) packets and (B) encode/decode them. (A) *needs* to be in the kernel. (B) doesn't, except for performance (when SLIP was first implemented, CPU resources were scarce enough that this made a big difference even on personal workstations. Not anymore). Dial on demand and chat script features have nothing to do in the kernel, because they don't need to be in and you generally don't care if you lose 2 milliseconds CPU for every 20+ seconds dialout procedure...$ > 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. Looks like you've never debugged anything in kernel space :-) Kernel-debugging space is *always* more difficult than user-space debugging, because starting and stopping user processes is a lot easier than starting and stopping kernels. > Good datacomm should focus on the 99% and not the 1%. Imagine if you moved > ethernet processing to user space to improve debugging? That's exactly the point. Fancy features are the 1% so they belong in user space. -- Pierre Beyssac pb@fasterix.frmug.fr.net pb@fasterix.freenix.fr {Free,Net,Open}BSD, Linux : il y a moins bien, mais c'est plus cher