From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 01:56:48 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8E1AA16A41C for ; Tue, 14 Jun 2005 01:56:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-66.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id 42B8243D1F for ; Tue, 14 Jun 2005 01:56:48 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.13.3/8.13.1) with ESMTP id j5E1ua3a099456; Mon, 13 Jun 2005 19:56:38 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 13 Jun 2005 19:57:42 -0600 (MDT) Message-Id: <20050613.195742.07655207.imp@bsdimp.com> To: hselasky@c2i.net From: "M. Warner Losh" In-Reply-To: <200506140250.26275.hselasky@c2i.net> References: <200506131412.38967.hselasky@c2i.net> <20050613.172307.81090793.imp@bsdimp.com> <200506140250.26275.hselasky@c2i.net> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: freebsd-hackers@freebsd.org Subject: Re: Obvious bug in /sys/i386/include/bus.h X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jun 2005 01:56:48 -0000 In message: <200506140250.26275.hselasky@c2i.net> Hans Petter Selasky writes: : On Tuesday 14 June 2005 01:23, M. Warner Losh wrote: : > In message: <200506131412.38967.hselasky@c2i.net> : > : > Hans Petter Selasky writes: : > : So can someone have this fixed, or is there a reason not to fix it. The : > : one who wrote the code has done the same mistake with every one of the : > : bus_space_XXXX that does memory mapped I/O. It currently breaks my : > : drivers. : > : > One isn't supposed to call these routines with count == 0. One could : > say your drivers are broken :-) : > : > Back when these were written, small optimizations like this were made : > to make things go faster. Now that cache sizes are bigger, a few : > extra instructions likely wouldn't affect things too much. Best to : > measure the effects of your proposed changes on real workloads... : : These functions are used to move smaller amounts of data. Larger amounts of : data should be moved using DMA. In this case functionality is more important : than performance?! At the time, programmed I/O was still big, and sometimes big amounts of data were moved with them.... I'm not saying we can't make the interfaces more forgiving. NetBSD's implementation of these functions also have this flaw... The code looks identical, and the histories of the file leads me to believe that they were adopted unchanged from the original NetBSD implementation 7 or 8 years ago... Anyway, please view my note as a historical 'this is why it is the way it is' not a 'it must be this way because'. Warner