[PATCH 7/8] ppc64: SPU file system

Arnd Bergmann arnd at arndb.de
Sun May 15 21:50:04 EST 2005


On Sünndag 15 Mai 2005 12:08, Arnd Bergmann wrote:
> On Sünndag 15 Mai 2005 08:29, Benjamin Herrenschmidt wrote:
> > Why not just write(pc) to start and read back status from the same
> > file ?

I just remembered the strongest reason against using write() to set
the instruction pointer: It breaks signal delivery during execution
of SPU code. With an ioctl or system call based interface, the kernel
simply updates the instruction pointer in process memory before
calling a signal handler. When/if the signal handler returns, it
does the same call again with the updated argument and the SPU
continues to fetch code at the point where it stopped.

If I do a read() based interface, there are no input parameters
at all, so restarted system calls work as well.

How about this one:

read() starts execution and returns the status value in a four
byte buffer.
Calling lseek() on the "run" file updates the instruction pointer,
so the library call can work like this plus error handling:

extern char *mapped_local_store;
uint32_t status;
int runfd = open("run", O_RDONLY);
lseek(runfd, INITIAL_INSTRUCTION, SEEK_SET);
do {
	read(runfd, &status, 4);
	if (status == SPU_DO_LIBRARY_CALL) {
		size_t arg = lseek(runfd, 4, SEEK_CUR) - 4;
		do_library_call(mapped_local_store + arg);
	}
} while (status != SPU_EXIT);

	Arnd <><



More information about the Linuxppc64-dev mailing list