Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 13 Jun 2005 19:57:42 -0600 (MDT)
From:      "M. Warner Losh" <imp@bsdimp.com>
To:        hselasky@c2i.net
Cc:        freebsd-hackers@freebsd.org
Subject:   Re: Obvious bug in /sys/i386/include/bus.h
Message-ID:  <20050613.195742.07655207.imp@bsdimp.com>
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>

next in thread | previous in thread | raw e-mail | index | archive | help
In message: <200506140250.26275.hselasky@c2i.net>
            Hans Petter Selasky <hselasky@c2i.net> writes:
: On Tuesday 14 June 2005 01:23, M. Warner Losh wrote:
: > In message: <200506131412.38967.hselasky@c2i.net>
: >
: >             Hans Petter Selasky <hselasky@c2i.net> 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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050613.195742.07655207.imp>