On 29 May 2002, Justin Carlson wrote:

Here's a patch against cvs that does the rename.  Unless anyone has
objections, Ralf, could  you apply this?

 That looks fine to me.  I'd keep the leading double underscore, though --
it acts as a warning sign the function is internal and low-level and thus
it should not be used without an appropriate justification.

While doing this, I've noticed that the whole mips tree is horribly
inconsistent in terms of the cache flushing syscalls (sys_cacheflush and
sys_sysmips->CACHE_FLUSH).  

 Ugh, it's not the only place of inconsistency...

Here's what the different ports appear to flush given one of these
syscall:

andes:  l1 and l2
lexra:  l1 icache
mips32: l1 icache/dcache
r3k:    l1 icache
r4k:    l1 icache/dcache
r5432:  l1 icache/dcache
r5900:  l1 icache/dcache
rm7k:   l1 icache/dcache
sb1:    l1 icache/dcache
sr7100: l1 and l2
tx39:   l1 icache
tx49:   li icache/dcache

Some of these are blatantly wrong with respect to the cacheflush
syscall; it defines flags for flushing the icache, dcache, or both.  In
the latter two cases, the lexra, r3k, and tx39 are not doing what was
requested.  I doubt this matters for any significant userspace app, but
it would be nice to at least be consistent.

 Well, at least r3k uses WT for dcache, so it really doesn't matter unless
what you want to achieve is to hit performance.  I suspect this is also
the case for the others that ignore dcache flushes.  The L1 vs L2 issue
should be investigated where applicable. 

 This reminds me to check ld.so (and libdl) for missing sys_cacheflush()
invocations as well...

As for the sysmips system call, I've  not been able to dig up the
semantics.  (Actually, I don't really see why we have both ways of
flushing the cache at all...some historical cruft?).  Anyone have a
helpful pointer to docs on the subject?

 It's compatibility crap, like the whole sysmips() stuff, I am afraid. 
Use sys_cacheflush() normally. 

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +