From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 14 00:49:36 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 EF4CB16A41C for ; Tue, 14 Jun 2005 00:49:36 +0000 (GMT) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe05.swip.net [212.247.154.129]) by mx1.FreeBSD.org (Postfix) with ESMTP id 624D343D53 for ; Tue, 14 Jun 2005 00:49:36 +0000 (GMT) (envelope-from hselasky@c2i.net) X-T2-Posting-ID: Y1QAsIk9O44SO+J/q9KNyQ== Received: from mp-217-209-246.daxnet.no ([193.217.209.246] verified) by mailfe05.swip.net (CommuniGate Pro SMTP 4.3.2) with ESMTP id 197706280; Tue, 14 Jun 2005 02:49:33 +0200 From: Hans Petter Selasky To: "M. Warner Losh" Date: Tue, 14 Jun 2005 02:50:24 +0200 User-Agent: KMail/1.7 References: <200506131412.38967.hselasky@c2i.net> <20050613.172307.81090793.imp@bsdimp.com> In-Reply-To: <20050613.172307.81090793.imp@bsdimp.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200506140250.26275.hselasky@c2i.net> 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 Reply-To: hselasky@c2i.net 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 00:49:37 -0000 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?! -- HPS