[Cbe-oss-dev] spufs syscalls

[Arnd Bergmann]

On Saturday 03 November 2007, Julio M. Merino Vidal wrote:
> So, why are these two syscalls an exception?  Did the design that  
> contained them as part of the file system turn out to be problematic?

Yes, though for the two calls we had slightly different reasons.
For spu_create, it solves the problem of lifetime management for
the spu context. We have a 'creat' system call for files that creates
a new instance of a file and returns a handle for the open file in
one atomic operation, but this does not exist for directories.
Only when you have the atomicity, you can have delete-on-close
semantics, which helps avoid leaving spu context behind after a program
crashes before removing the contexts.

For spu_run, there are both performance and style reasons to use
a separate system call. The previous implementation had a file
called 'run' that you did a read() operation on to start the spu.
Unless you are a plan9 person, this is completely counterintuitive,
and it means that you can't really pass parameters into the run
operation, forcing you to do additional system calls in the fast
path.

At one point, the idea for the two system calls was to have them
generic enough so they can be used by other subsystems apart from
spufs for similar purposes, but they evolved away from that.
If we should actually get some similar file systems in the future,
I'd guess we have to create new syscalls that are generic enough
to cover them all.

	Arnd <><