there is one more good reason to ... : the Impact Xserver needs to do
a cacheflush(a,w,DCACHE) as part of the refresh-sequence.
And hence requires a sys_cacheflush, let's say, more conforming to the
man-page (or some disgusting new ioctl in the Impact kernel-driver to
do an equivalent operation ;-)
kind regards :-)
On Wed, 11 Feb 2009, Ralf Baechle wrote:
> Date: Wed, 11 Feb 2009 13:16:49 +0000
> From: Ralf Baechle <email@example.com>
> To: naresh kamboju <firstname.lastname@example.org>
> Cc: email@example.com
> Subject: Re: cacheflush system call-MIPS
> On Tue, Feb 10, 2009 at 08:46:58PM +0530, naresh kamboju wrote:
> > Hi Mr. Ralf,
> > I have tried to test cacheflush system call to generate EINVAL
> > on Toshiba RBTX4927/RBTX4937 board with 2.6.23 kernel.
> > I have referred latest Man pages there is a bug column.
> > Please let me know whether this is bug in source code or in the man page.
> > (arch/mips/mm/cache.c)
> The answer is probably a bit of both. The API and error behaviour was
> defined by the earlier MIPS UNIX variant RISC/os or possibly even earlier.
> Gcc relies on the existence of this syscall - or rather a library
> function which usually will be implemented to execute this syscall because
> the operating requires kernel priviledges - so Linux had to get an
> implementation as well.
> Now in practice there is only one good reason to perform explicit
> cacheflushes from userspace and that's to ensure I-cache coherency and
> that's the one thing the Linux implementation of cacheflush(2) is trying
> to do. Therefore the implementation ignores the cache argument and
> will instead perform whatever is necessary to guarantee I-cache coherency -
> whatever this means on a particlar implementation.
> Similarly the implementation won't verify that every byte of the range
> is accessible. For a large range it instead may choose to perform a full
> writeback / invalidation of some or all parts of the cache hierarchy
> which might mean there will not be an error return even though part of
> the address space may not be accessible.
> Talking about bugs - the "BUGS" section of the man page is wrong. A full
> cacheflush is only performed if this is considered to be faster than a
> cacheline-by-cacheline flush.