From owner-freebsd-hackers Fri Dec 27 15:15:50 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id PAA13148 for hackers-outgoing; Fri, 27 Dec 1996 15:15:50 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.4/8.8.4) with SMTP id PAA13143 for ; Fri, 27 Dec 1996 15:15:47 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id QAA25429; Fri, 27 Dec 1996 16:06:08 -0700 From: Terry Lambert Message-Id: <199612272306.QAA25429@phaeton.artisoft.com> Subject: Re: ipretard.c selective tcp/ip queues and throughput limiters To: julian@whistle.com (Julian Elischer) Date: Fri, 27 Dec 1996 16:06:08 -0700 (MST) Cc: luigi@labinfo.iet.unipi.it, proff@iq.org, danny@panda.hilink.com.au, hackers@FreeBSD.ORG In-Reply-To: <32BEE215.167EB0E7@whistle.com> from "Julian Elischer" at Dec 23, 96 11:48:37 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > but as Kieth sklower at CSRG told me.. > There's got to be a way to make it possible for essoteric or unusual > modules to be implimented OUT OF THE KERNEL, or > they are > (1) hard to prototype > (2) increasing the complexity of what IS in the kernel beyond the > point of debuggability :) You must abstract both the top and bottom end of the modules sufficiently; most modules are only abstracted sufficiently at the top end. For instance, for FS's, the VFS is well defined, but the VM interface for doing actual disk I/O is not well abstracted at all. This is what I've been calling "layering problems". It is definitely a goal of mine to allow a module to be debugged in user space with a source level debugger. Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.