[I replied to parts of this in reponse to a later message]
On Thu, 6 Sep 2001, Julian Elischer wrote:
> typedef void Xcopy( void volatile *, void volatile *, int);
> #define VBCOPY(A,B,L) (*(Xcopy *)&bcopy)((A),(B),(L))
> typedef void Xzero( void volatile *, int);
> #define VBZERO(A,L) (*(Xzero *)&bzero)((A),(L))
> This is kind-of a hack but a couple of things come to mind:
> 1/ Most drivers should probably use volatile mor ethan they do if they
> structures with hardware. These often need bcopy(), so this is probably
> not an unlikely
They probably shouldn't use shared hardware/software structs.
> 2/ initializing these volatile structures with bzero is also not
> 3/ It probably wouldn't hurt if bzero ALWAYS had a volatile pointer
> and it may remove several warnings in other drivers as well.
I think only one-field-at-a-time initialization and duplication of
volatile structs is right in general. Consider weird hardware that
has some 32-bit registers and some 8-bit registers where it is essential
to do only 32-bit accesses to the 32-bit registers and only 8-bit accesses
to the 8-bit registers.
> Is this hack to horrible to contemplate?
> Is it a reasonable thing thing to define bzero to take a volatile
This would prevent certain optimizations. Some people want to use
memset() instead of bzero(). It's clear that memset() doesn't take
volatile pointers (the C standard says so). We could have special
versions of all copying and memory-setting functions, ones which take
all combinations of volatiles and consts, but 2 versions is already
too many IMO. We already have zillions of versions for bus_space.
> BTW what is ovbcopy() for? is it for overlaping?
Yes. It is moot in BSD, because plain BSD bcopy() handles overlapping
copies, at least in userland, and it would be confusing for it to have
differernt behaviour in the kernel. Thus ovbcopy is essentially just
an an alternative entry point for bcopy. It was mainly used in ancient
> I notice that KAME ar the major users of it, and it's defined to be the
but now it is used a lot here (for portability?).
> I also notice that NetBSD are (or were) having a kill
> ovbcopy/bcopy/bzero effort
> to replace them with memcpy and friends.
I have a kill memcpy/memset effort :-).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message