lkml.org 
[lkml]   [2005]   [May]   [15]   [last100]   RSS Feed
Views: [more markup]  [less markup]  [headers]  [forward] 
 
Messages in this thread
/
FromArnd Bergmann <>
SubjectRe: [PATCH 7/8] ppc64: SPU file system
DateSun, 15 May 2005 13:50:04 +0200
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 <><
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-05-15 14:12    [from the cache]
©2003-2008