Ignatios Souvatzis <is@jocelyn.rhein.de> writes:

> $Id: cacheflush.txt,v 1.2 1998/12/02 21:30:36 is Exp $
> 
>    Name
>      cacheflush - flush the instruction cache, data cache, or both
> 
>    Syntax
> -    #include <mips/cachectl.h>
> +    #include <cacheflush.h>

why not cachectl.h, so that if we want/need to add more/different ops
later, we can do so w/o the name sucking?

eventually, i can imagine a desire to put memory barriers into a
similar set of interfaces.

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

"how do you flush all of memory?"

no, addr == 0 and nbytes == INT_MAX won't do it.

even if nbytes is unsigned and you use UINT_MAX, you lose.  8-)

maybe 'unsigned long' or 'size_t' nbytes.

also, is there reason to use 'char *' rather than 'void *'?  the
memory's type doesn't really matter...


>      ICACHE         Flush only the instruction cache.
> 
>      DCACHE         Flush only the data cache.
> 
>      BCACHE         Flush both the instruction and data caches.

Why aren't these a bitmask?  I.e. why have BCACHE rather than
ICACHE|DCACHE?


> +    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.

this description has interesting implications.  for instance, it can
be intrepreted to mean that in an MP system, writes have to be
propagated only far enough to be seen by whatever refreshes the local
icache, i.e. if you write to address 'foo' on processor A, and then do
a BCACHE 'flush' on foo, and then do a BCACHE flush on foo on
processor B, and then jump to 'foo' on processor B, you may get old
data.

I suggest you specify it more carefully.  i would advise looking at
the Alpha Architecture Reference Manual's discussion of MP cache
synchronization.


yes, i know we don't really use more than one processor on MP systems
yet, but i'm still holding out hope...


>      [EFAULT]       Some or all of the address range in the addr to
>                     (addr+nbytes-1) are not accessible.

Is that really a bug?  I'm not convinced it should be...



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.