Subject: Re: cacheflush() proposal
To: Ignatios Souvatzis <email@example.com>
From: Jason Thorpe <firstname.lastname@example.org>
Date: 12/02/1998 16:52:41
On Wed, 2 Dec 1998 23:56:06 +0100
Ignatios Souvatzis <email@example.com> wrote:
> - the CPU has none or unified caches: the function is a no-op; possibly an
> empty define in the header file, and a return(0) or equivalent in libc.
> - the CPU supports user-level instructions for this (e.g., PPC): the
> implementation is just (possibly inline) code to do the job. Look at what
> gcc does for objc purposes.
> - the CPU needs supervisor code: implement as trap call, sysarch() call or
> whatever you're already doing... remember, gcc's libgcc already contains
> code to do this for the benefit of Objective C, so something must exist
I think that, for consistency, it should always be a function call to
perform the flush, i.e. not an inline or macro in a header file. This
ensures that the symbol will always be avalable in the library, for cross-
Also, so that e.g. compilers that emit function calls can avoid namespace
pollution, there should be _cacheflush(), and a weak or indirect alias
cacheflush(). Compilers should use the former, in case an application
provides a "cacheflush()" that flushes it's pathname cache, or whatever :-)
> cacheflush - flush the instruction cache, data cache, or both
> - #include <mips/cachectl.h>
> + #include <cacheflush.h>
How about <sys/cachectl.h>, and we just be basically compatible with the
IRIX interface? Maybe also implement cachectl(2)? (make a range cacheable
> cacheflush(addr, nbytes, cache)
> char *addr;
> int nbytes, cache;
...add _cacheflush(), and possible _flush_cache() (per IRIX interface).
> Flushes contents of indicated caches for user addresses in the range of
> addr to (addr+nbytes-1). The cache parameter is one of the following:
> ICACHE Flush only the instruction cache.
> DCACHE Flush only the data cache.
> BCACHE Flush both the instruction and data caches.
> + An implementation on a particular CPU is allowed to do nothing (if the
> + CPU has no or unified caches) or flush more than requested (if the CPU
> + doesn't provide fine-grained control over its caches), as long as a
> + BCACHE operation guarantees that all data written to the address range
> + before cacheflush() is guaranteed to be visible as instruction stream
> + afterwards.
> Return Values
> The cacheflush system call returns 0 when errors are not detected. If
> errors are detected, the cacheflush system call returns -1 with the
> error cause indicated in errno.
> [EFAULT] Some or all of the address range in the addr to
> (addr+nbytes-1) are not accessible.
> [EINVAL] The cache parameter is not ICACHE, DCACHE, or BCACHE.
Jason R. Thorpe firstname.lastname@example.org
NASA Ames Research Center Home: +1 408 866 1912
NAS: M/S 258-5 Work: +1 650 604 0935
Moffett Field, CA 94035 Pager: +1 650 940 5942