So,

between 2 days ago and 0030 this morning CET I've received a lot of feedback
on this issue, on communication channels that are more or less private. As I
don't see that feedback reflected here (as I asked for), let me summarize
those comments and important earlier list messages (anonymized where not on
this list).

+ Chris Demetriou agreed with Eduardo Horvath in that we should define an
interface in terms of abstract operations one might want to do, not in terms
of particular memory/cache architecture implementations. [[I don't know how
much he agrees with the full proposal, especially as transformed by myself.]]

+ 1 person expressed it is a good thing to return error codes as function
value, not in errno (because it avoids some reentrancy problems).

[[BUT: we need to provide a hack around this problem anyway, so this isn't
a hard argument, I think.]]

- Some people said the MIPS ABI for the cache synchronization provides
enough functionality, and 3rd-party programs (that need it) are likely to
know how to use it, so we should not invent a new interface. (Jason Thorpe
expressed this earlier on this list).

[[I feel this is a valid argument. Additionally whatever I wanted to do with
this work can be done with the MIPS ABI.

BUT:
Ultrix/mips uses <mips/cachectl.h> to define cacheflush() and
and the cachectl() functions.

NetBSD/mips uses <mips/cachectl.h> to define cacheflush() aliased to
_cacheflush(), and declare cachectl() (but I didn't find the implementation 
of cachectl())

IRIX instead uses <sys/cachectl.h> to define cachectl(), and cacheflush()
aliased to _flush_cache().

Which one do we want to provide in a generic interface? Or maybe another one?
How will 3rd party programmers think about any one of these choices?

BUT2: the Ultrix and IRIX man pages I looked at or have been shown do not
state what happens if a machine has more than one instruction cache
(e.g., multi-cpu machines).  As it was a single-CPU machine, and maybe
a non-MP-capable IRIX version, this was to be expected. I feel we
should define this if we provide a general interface.

BUT3: the MIPS ABI returns error codes in errno. See above.]]

- Some people claim we don't need a distinction between global and local
cache synchronizing.

[[I know of one potential architecture where I'd disagree, but the application
of a cheap local (no system call) synchronization on a multi-cpu machine may
well be limited.]]

- I did a bit code and manual browsing myself and noticed that mmap() can 
be told to make the region semaphore-safe, which would make userland
memory barriers for userland semaphores (as implemented using CAS/CAS2 on m68k
or maybe the reservation stuff on PPC) unneeded. Multi-CPU machines that
do NOT provide coherency in hardware should be thr^H^H^Htaught to make share
regions uncached, maybe... you'll have a performance penalty in either case.

				+++

I don't feel any longer capable to handle this. As far as I can tell, there
is no consensus about whether the same interface should be used for memory
barriers, or whether we need them outside the kernel, or (if using the MIPS ABI
at all) whether the MIPS cachectl() should be generally implemented
additionally to the MIPS cacheflush().

				+++

Btw, the original problem (see PR 4951) that started this discussion
can well be handled by defining a m68k specific function in libarch
modeled after libarch(arm32)::arm32_sync_icache.

Regards,
	Ignatios Souvatzis