> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
