On Sun, Feb 07, 1999 at 06:43:37PM -0800, Jason Thorpe wrote:
> On Sun, 7 Feb 1999 13:32:10 +0100 
>  Ignatios Souvatzis <is@jocelyn.rhein.de> wrote:
> 
>  > > DEFINITION (taken from eeh, enhanced by myself)
>  > > 
>  > > 	#include <sys/memsync.h>
>  > > 
>  > > 	void memsync(start, size, what), weakly aliased to
>  > > 	void _memsync(start, size, what)
>  > > 	void* start;
>  > > 	size_t size;
>  > > 	int what;
>  > 
>  > Should it really be void memsync(...)?
> 
> I really am bothered by the notion of naming this memsync() when the
> ABI for at least one of our supported architectures REQUIRES that it
> be called something else... So, what, are we going to provide that
> symbol ONLY on that arch (MIPS), or are we also going to have that API
> to this functionality available?

We won't delete pre-existing APIs to the functionality, that is:

- we wont delete the MIPS cacheflush()  (or what was its name) and the
  libarch function on ARM32
- we wont make trap #12 on m68k unusable
- we wont manipulate the assembler to not output the PPC cache manipulation
  instructions

That is: knowledgable programmers can use the architecture-specific interfaces
if they so wish.

All I want is an interface that can be used on m68k. I was forced to make it
generic (well, its a good thing to have a generic one).

	-is