Subject: Re: memsync() proposal (Was: Re: cacheflush() proposal)
To: Jason Thorpe <email@example.com>
From: Ignatios Souvatzis <firstname.lastname@example.org>
Date: 02/08/1999 17:15:47
On Sun, Feb 07, 1999 at 06:43:37PM -0800, Jason Thorpe wrote:
> On Sun, 7 Feb 1999 13:32:10 +0100
> Ignatios Souvatzis <email@example.com> 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
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).