Date: Fri, 07 Sep 2001 12:55:58 -0700 From: Bakul Shah <bakul@bitblocks.com> To: Julian Elischer <julian@vicor-nb.com> Cc: Bruce Evans <bde@zeta.org.au>, John Baldwin <jhb@FreeBSD.ORG>, current@FreeBSD.ORG Subject: Re: RFC: hack volatile bzero and bcopy Message-ID: <200109071956.PAA29905@thunderer.cnchost.com> In-Reply-To: Your message of "Fri, 07 Sep 2001 11:30:22 PDT." <3B99123E.FEA51AD6@vicor-nb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200109071956.PAA29905>