Date: Sun, 30 Jul 2000 15:05:47 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matthew Jacob <mjacob@feral.com> Cc: Archie Cobbs <archie@whistle.com>, Peter Wemm <peter@FreeBSD.org>, cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_fxp.c Message-ID: <Pine.BSF.4.21.0007301444110.9288-100000@besplex.bde.org> In-Reply-To: <Pine.BSF.4.10.10007291251510.67255-100000@beppo.feral.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
> 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.
> > Dumb question. Why don't we just have a vbcopy()? I.e.:
> >
> > void vbcopy __P((const volatile void *from, volatile void *to, size_t len));
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.
Bruce
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?Pine.BSF.4.21.0007301444110.9288-100000>