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."
>
>