Subject: Re: Possibly naiive question about bus_space_barrier & friends
To: Jason R Thorpe <thorpej@wasabisystems.com>
From: David Brownlee <abs@netbsd.org>
List: tech-kern
Date: 10/24/2001 22:47:54
	Did you suggest a while back having a debug version of the
	bus_space functions which would show up any abuses on i386 or
	similar? (Apologies if I'm misremembering)

-- 
		David/absolute		-- www.netbsd.org: No hype required --


On Thu, 18 Oct 2001, Jason R Thorpe wrote:

> On Thu, Oct 18, 2001 at 01:01:29PM -0700, Monroe Williams wrote:
>
>  > The thing which surprises me is that bus_space_barrier() is defined as a
>  > no-op, and the various bus_space_read*() and bus_space_write*() functions
>  > all call through to functions in pio.h which end with:
>  >
>  > __asm__ volatile("eieio; sync");
>  >
>  > Aside from the fact that sync AFAIK performs a strict superset of the
>  > operations performed by eieio, this seems like it violates the spirit of
>  > what bus_space_barrier() is intended for.
>  >
>  > Am I missing something basic here, or are the MI drivers in the various
>  > macppc ports being dreadfully inefficient?
>
> You are correct in that it violates the spirit.  The problem is that
> changing all the drivers in the tree to use barriers correctly is a...
> daunting task.  Therefore, the only way to make them work until they
> do is implicit barriers.
>
> It might be nice to have _nb ("no barrier") versions of the bus_space
> operations so as to explicitly hint that a barrier operation will be
> used later... so that we can continue to be lazy and not use barriers
> in the current scheme.  "Or something."
>
>