From owner-freebsd-current Fri Sep 7 12:56:13 2001 Delivered-To: freebsd-current@freebsd.org Received: from thunderer.cnchost.com (thunderer.concentric.net [207.155.252.72]) by hub.freebsd.org (Postfix) with ESMTP id 3F4DA37B403; Fri, 7 Sep 2001 12:56:09 -0700 (PDT) Received: from bitblocks.com (adsl-209-204-185-216.sonic.net [209.204.185.216]) by thunderer.cnchost.com id PAA29905; Fri, 7 Sep 2001 15:56:16 -0400 (EDT) [ConcentricHost SMTP Relay 1.14] Message-ID: <200109071956.PAA29905@thunderer.cnchost.com> To: Julian Elischer Cc: Bruce Evans , John Baldwin , current@FreeBSD.ORG Subject: Re: RFC: hack volatile bzero and bcopy In-reply-to: Your message of "Fri, 07 Sep 2001 11:30:22 PDT." <3B99123E.FEA51AD6@vicor-nb.com> Date: Fri, 07 Sep 2001 12:55:58 -0700 From: Bakul Shah Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > well this is th idea, because I think that bcopy is probably a safe > operation > on the volatile structures if the driver knows that they are presently > owned by it.. (e.g. mailboxes) *probably* safe? For truly volatile memory bzero & bcopy are *not* safe. Anyone remember the origial 68000's `clr' instruction that did read followed by write to clear memory? You _can_ use that clr instn in bzero if the passed in ptr does not point to volatile memory. bcopy can also use efficiency tricks if the src & dst are not aligned on the same 4 byte boundary. AMD 29k for example had an `extract' instruction that allowed unaligned copying at memory bandwidth. But usually one punted on boundary conditions and didn't think twice about refetching a word. One can't be so cavalier if bcopy accepted volatile ptrs. You can use similar tricks on systems with wide cache lines and some of these tricks would be illegal on volatile memory. > out-of order is probably ok for a buffer if you know that it's > presently yours to write into. If the area being bcopied/bzeroed has this behavior why not remove the volatile from the struct ptrs instead of "fixing" bcopy/bzero? > 2/ add to the prototype of bzero and bcopy so that volatile pointers are > acceptable > arguments. (I don't see any reason to not do this). Because the (informal) defn of bcopy/bzero does not allow volatile arguments. You are wagging the dog. Why not just cast these ptrs at the call sites where you _know_ bcopy, bzero use is safe. That sort of documents what is going on without opening a big hole. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message