From owner-freebsd-arch@FreeBSD.ORG Wed Jun 18 10:47:37 2003 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id A5E2437B401 for ; Wed, 18 Jun 2003 10:47:37 -0700 (PDT) Received: from regina.plastikos.com (216-107-106-250.wan.networktel.net [216.107.106.250]) by mx1.FreeBSD.org (Postfix) with ESMTP id A8FD143F85 for ; Wed, 18 Jun 2003 10:47:36 -0700 (PDT) (envelope-from fullermd@over-yonder.net) Received: from mortis.over-yonder.net (adsl-33-235-56.jan.bellsouth.net [67.33.235.56]) (using TLSv1 with cipher EDH-RSA-DES-CBC3-SHA (168/168 bits)) (No client certificate requested) by regina.plastikos.com (Postfix) with ESMTP id DDDCE6EEB9; Wed, 18 Jun 2003 13:47:35 -0400 (EDT) Received: by mortis.over-yonder.net (Postfix, from userid 100) id D2E9620F30; Wed, 18 Jun 2003 12:47:33 -0500 (CDT) Date: Wed, 18 Jun 2003 12:47:33 -0500 From: "Matthew D. Fuller" To: Poul-Henning Kamp Message-ID: <20030618174733.GC10127@over-yonder.net> References: <41012.1055950519@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <41012.1055950519@critter.freebsd.dk> User-Agent: Mutt/1.4.1i-fullermd.1 X-Editor: vi X-OS: FreeBSD cc: arch@freebsd.org Subject: Re: userland access to devices is moving! X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Jun 2003 17:47:37 -0000 On Wed, Jun 18, 2003 at 05:35:19PM +0200 I heard the voice of Poul-Henning Kamp, and lo! it spake thus: > > I sat down and hacked up a simple prototype to test the concept I > have been rambling about for some years: Going directly from > filedescriptor to device driver thus bypassing the vnode, devfs and > specfs layer. Speaking as somebody whose reach of mailing lists notably exceeds his grasp (as it always should be; otherwise what fun is it?), I often find myself a little in the dark on what these sort of things really /mean/ to the system in the end, and I think it would be a nice extension of these sort of posts/proposals to have a sentence of summary, along the lines of: What does this change /mean/ to the system as a whole? Is this A) Cleaner code, so bugs can be found and fixed quicker and better, B) Architectural improvement, so new features are easier to add on cleanly and well, or C) A real-world performance improvement. The benchmark you posted certainly shows a significant improvement in SOMETHING; but is it a something that will make mail servers or web servers or file servers or workstations perk up? I realize that they're not really exclusive conditions, and are mostly intertangled. And, for that matter, that most changes don't get done because of A, B, C, or any combination thereof, but more often because "This is the ugliest mess I've ever seen and it's been haunting my dreams for years, and I anyway I thought it would be fun to mess with." But I for one would appreciate a quick note of a higher-level view of where this can move us. Of course this means I'm out of my depth. But everybody needs a hobby :-} -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet"