Date: Fri, 7 Sep 2001 21:20:42 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: <julian@elischer.org> Cc: <current@FreeBSD.ORG> Subject: Re: RFC: hack volatile bzero and bcopy Message-ID: <20010907205856.M38309-100000@alphplex.bde.org> In-Reply-To: <3B981982.4E939CDF@vicor-nb.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[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 > share > structures with hardware. These often need bcopy(), so this is probably > not an unlikely > combination.. They probably shouldn't use shared hardware/software structs. > 2/ initializing these volatile structures with bzero is also not > unlikely. > 3/ It probably wouldn't hurt if bzero ALWAYS had a volatile pointer > argument. > 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. > questions: > Is this hack to horrible to contemplate? Yes. > Is it a reasonable thing thing to define bzero to take a volatile > argument. 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 sources ... > 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 :-). Bruce 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?20010907205856.M38309-100000>