From owner-cvs-all Sat Jul 29 22:41: 5 2000 Delivered-To: cvs-all@freebsd.org Received: from netplex.com.au (adsl-63-207-30-186.dsl.snfc21.pacbell.net [63.207.30.186]) by hub.freebsd.org (Postfix) with ESMTP id A096B37B9A1; Sat, 29 Jul 2000 22:41:00 -0700 (PDT) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (peter@localhost [127.0.0.1]) by netplex.com.au (8.9.3/8.9.3) with ESMTP id WAA59053; Sat, 29 Jul 2000 22:40:46 -0700 (PDT) (envelope-from peter@netplex.com.au) Message-Id: <200007300540.WAA59053@netplex.com.au> X-Mailer: exmh version 2.1.1 10/15/1999 To: Bruce Evans Cc: Matthew Jacob , Archie Cobbs , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/pci if_fxp.c In-Reply-To: Date: Sat, 29 Jul 2000 22:40:45 -0700 From: Peter Wemm Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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