Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 29 Jul 2000 22:40:45 -0700
From:      Peter Wemm <peter@netplex.com.au>
To:        Bruce Evans <bde@zeta.org.au>
Cc:        Matthew Jacob <mjacob@feral.com>, Archie Cobbs <archie@whistle.com>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org
Subject:   Re: cvs commit: src/sys/pci if_fxp.c 
Message-ID:  <200007300540.WAA59053@netplex.com.au>
In-Reply-To: <Pine.BSF.4.21.0007301444110.9288-100000@besplex.bde.org> 

next in thread | previous in thread | raw e-mail | index | archive | help
Bruce Evans wrote:
> On Sat, 29 Jul 2000, Matthew Jacob wrote:
> 
> > Not a dumb question, but I'd suggest that bcopies from a volatile source at
> > leat should be discouraged.
> 
> They are just broken, since bcopy() may do optimizations that aren't valid
> for volatile data.  E.g., the i586 bcopy sometimes reads the source twice
> (to prefetch it the first time).  The data may be copied out of order or
> written more than once.

In this particular case it is ok.  The data being copied is "part time"
volatile only.  It does not matter what or how bcopy may optimize as it is
not being used on data that is volatile *at the time of the bcopy*.

> > On Sat, 29 Jul 2000, Archie Cobbs wrote:
> > 
> > > Peter Wemm writes:
> > > >   Log:
> > > >   "Fix" cast qualifier warnings using the uintptr_t intermediate trick.
> 
> This seems to just hide the problem in if_fxp.c.

No, the bcopy is safe in this case.  We once used bcopy on real volatile
data but that did get fixed long ago.

> > > Dumb question. Why don't we just have a vbcopy()? I.e.:
> > > 
> > >   void vbcopy __P((const volatile void *from, volatile void *to, size_t l
    en));
> 
> Most volatile memory is device memory so it should be copied using
> bus_space_{read,write}*.  If you have volatile variables in a struct,
> then accessing the struct (or the variables) using bcopy is simplistic.
> The variables can normally only be accessed safely using atomic instructions
> or after acquiring a lock.  If things are locked, then the variables aren't
> really volatile.

In the fxp case, the volatile memory is *not* device memory.  One example
use was where bcopy was being used to set up a descriptor that was *later*
going to be fed to the hardware.  Once it has been activated, then it needs
volatile handling (and does get special handling in if_fxp).

> Bruce
> 
> 

Cheers,
-Peter
--
Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
"All of this is for nothing if we don't go to the stars" - JMS/B5



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message




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