Date: Wed, 28 Dec 2011 16:47:40 +1100 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Sergey Kandaurov <pluknet@gmail.com> Cc: "freebsd-net@freebsd.org" <freebsd-net@freebsd.org>, Sean Bruno <seanbru@yahoo-inc.com> Subject: Re: i386 compile sys/dev/ie Message-ID: <20111228162621.G936@besplex.bde.org> In-Reply-To: <CAE-mSOLDrPLkVbM8i-1q=wzMdF_Kz1FJNJqtW-4tnC0_VWvrKA@mail.gmail.com> References: <1325015120.17645.7.camel@hitfishpass-lx.corp.yahoo.com> <CAE-mSOLDrPLkVbM8i-1q=wzMdF_Kz1FJNJqtW-4tnC0_VWvrKA@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 28 Dec 2011, Sergey Kandaurov wrote: > On 27 December 2011 23:45, Sean Bruno <seanbru@yahoo-inc.com> wrote: >> Doing a lot of compiles recently and keep noting this noise in >> sys/dev/ie: >> >> /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c: In function >> 'ieget': >> /dumpster/scratch/sbruno-scratch/head/sys/dev/ie/if_ie.c:682: warning: >> passing argument 1 of 'bcopy' discards qualifiers from pointer target >> type > [snip similar] > > These type of errors are because bzero takes a volatile argument but wants > a non-volatile. This can be "solved" by casting to remove volatile modifier. You mean that the warning about these errors can be broken by casting to remove the volatile qualifier (except casting has no effect except to do the same thing that the prototype does, and should cause a warning from -Wcast-qual). Either the memory is not actually volatile, in which case the pointer to it is misdeclared, or it is volatile, in which case using bcopy() on it gives undefined behaviour, depending on how bcopy() os implemented (bcopy() might access the memory out of order, or more than once, or with granularity that doesn't work). If the memory consists of device registers, then it is another error to access it using bcopy() instead of bus-space. IIRC, the volatiles in ie are: - the result of being a very old driver that was never converted to using bus space. No one wants to waste time converting it. - some for device memory and some for driver memory - the result of excessive use of volatile for non-volatile memory, especially for the non-device part, since when it was written in 1992/3, the general useless of volatile wasn't well understood but you could trick the compiler into working by sprinkling volatile. Originally, splimp() should have been used to make most accesses non- volatile. Now, mutex locking should do this even better. splimp() is no longer used, but there is still a bogus comment documenting where it "should" be used, and no comments about its mutex locking. > These were used in probe routine and are left from the newbus rewrite. > I hacked ie a bit to build cleanly. [Not sure if I did this correctly.] Use of the __DEVOLATILE() abomination is never correct. It exploits the bug that -Wcast-qual is broken for casts through [u]intptr_t. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111228162621.G936>