Subject: Re: cacheflush() proposal
To: Ignatios Souvatzis <is@jocelyn.rhein.de>
From: Jason Thorpe <thorpej@nas.nasa.gov>
List: tech-userlevel
Date: 12/02/1998 16:52:41
On Wed, 2 Dec 1998 23:56:06 +0100 
 Ignatios Souvatzis <is@jocelyn.rhein.de> 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
 >   already.

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-
platform consistency.

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 :-)

 >    Name
 >      cacheflush - flush the instruction cache, data cache, or both
 > 
 >    Syntax
 > -    #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
or uncacheable)

 > 
 >      cacheflush(addr, nbytes, cache)
 >      char *addr;
 >      int nbytes, cache;

...add _cacheflush(), and possible _flush_cache() (per IRIX interface).

 > 
 >    Description
 >      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.
 > 
 >    Diagnostics
 > 
 >      [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                                       thorpej@nas.nasa.gov
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