Re: RFC: hack volatile bzero and bcopy
On Fri, 7 Sep 2001, Bakul Shah wrote: 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? One reason is that the memory might be normal at the time of the bcopy (because you have locked out concurrent accesses to it), but volatile at other times. I think this should be handled in general by declaring it as normal and always locking it. 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. FreeBSD turns on -Wcast-qual in order to prevent inadvertant loss of type qualifiers, so using explicit casts just moves the warning from the implicit casts caused by the prototype to the implicit casts. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: hack volatile bzero and bcopy
In message [EMAIL PROTECTED] Bruce Evans writes: : In the case of if_ie.c and bcopy(), bcopy() is not suitable for copying : memory that doesn't behave like RAM. Some optimized versions of it : do out of order and/or repeated copies. This might be very bad for : volatile device memory. I think rewriting if_ie.c to use bus_space : would make most of the warnings go away automatically. Right. bus_space_read/write_N likely should be used instead. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: hack volatile bzero and bcopy
Bruce Evans wrote: This just breaks the warning. 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) The correct answer would be, as you suggest, bus-space operations but that's more work than this driver really warrants at this stage. It's just be acceptable in my eyes to break the warnings as you put it. (remember, pointless warnings distract from real warnings). In the case of if_ie.c and bcopy(), bcopy() is not suitable for copying memory that doesn't behave like RAM. Some optimized versions of it do out of order and/or repeated copies. This might be very bad for volatile device memory. I think rewriting if_ie.c to use bus_space would make most of the warnings go away automatically. out-of order is probably ok for a buffer if you know that it's presently yours to write into. I'd like to to some of the following: 1/ add the hack to places that do this to reduce distracting warning messages or 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). To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: hack volatile bzero and bcopy
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
RE: RFC: hack volatile bzero and bcopy
On Thu, 6 Sep 2001, John Baldwin wrote: On 07-Sep-01 Julian Elischer wrote: Here is a hack to remove the 20 or so warning messages from if_ie.c No hacks please. I fixed some of these locally a few years ago without using any hacks, but gave up. if_ie.c should be rewritten to not use volatile qualifiers to a fault. Most of them are due to the supply of volatile pointers to bcopy and bzero. I do the following to produce macros that call bzero and bcopy, but don't produce warning messages when called with volatile arguments. 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 just breaks the warning. sys/cdef.h already has some rather general purpose macros for thsi sort of thing in the form of __DEVOLATILE(), __DECONST(), and __DEQUALIFY(). These will be terminated with extreme prejudice. Making it easy to break the warnings for removing const qualifiers is bad enough, but there are cases where removing const qualifiers is not a bug. I can't think of any cases where removing volatile qualifiers is not a bug. Well, there are cases where volatile memory becomes unvolatile because you lock it while it is being accessed, but these cases are probably better handled by not declaring it as volatile. In the case of if_ie.c and bcopy(), bcopy() is not suitable for copying memory that doesn't behave like RAM. Some optimized versions of it do out of order and/or repeated copies. This might be very bad for volatile device memory. I think rewriting if_ie.c to use bus_space would make most of the warnings go away automatically. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: RFC: hack volatile bzero and bcopy
[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 [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: RFC: hack volatile bzero and bcopy
On 07-Sep-01 Julian Elischer wrote: Here is a hack to remove the 20 or so warning messages from if_ie.c Most of them are due to the supply of volatile pointers to bcopy and bzero. I do the following to produce macros that call bzero and bcopy, but don't produce warning messages when called with volatile arguments. 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)) sys/cdef.h already has some rather general purpose macros for thsi sort of thing in the form of __DEVOLATILE(), __DECONST(), and __DEQUALIFY(). -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: RFC: hack volatile bzero and bcopy
Actually I just discoverd that you can do: int function (volatile const *); (I guess you say you will not writ eto it, but that it may change of its own volition at times) anyhow setting this in bcopy would remove a heck of a lot of warnings in the kernel. On Thu, 6 Sep 2001, John Baldwin wrote: On 07-Sep-01 Julian Elischer wrote: Here is a hack to remove the 20 or so warning messages from if_ie.c Most of them are due to the supply of volatile pointers to bcopy and bzero. I do the following to produce macros that call bzero and bcopy, but don't produce warning messages when called with volatile arguments. 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)) sys/cdef.h already has some rather general purpose macros for thsi sort of thing in the form of __DEVOLATILE(), __DECONST(), and __DEQUALIFY(). thanks, I'll go look at them. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
