[Cbe-oss-dev] PATCH [4/7] decouple spu scheduler from spufs_spu_run [asynchronous scheduling]

[Christoph Hellwig]

On Fri, Nov 23, 2007 at 06:51:14PM -0200, Luke Browning wrote:
> Also, if the program is ignoring SIGBUS or SIGILL, then the system call
> fails with EFAULT which is really odd as the failure is not related to
> any copyin/copyout operations associated with system call parameters.  
> 
> It seems more intuitive to me to map return codes from the kernel
> handlers for class 0 and 1 to specific errnos and return those values so
> that the controlling thread knows what happened.  There is no standard
> here that says we have to return EINTR, although I would return that for
> asynchronous signals.  At least, we could explain the immediate
> condition if not how to handle it.
> 
> Does anybody know how this is supposed to work?  Is it documented? 

As you mention the application gets some information on what happened by
the signal payload.  There's at least one testcase that uses this to
mprotect on a memory protetion failure (the one Andre fixed a while
ago).   But I doubt anyone spent a lot of though on the interface, this
might be something for the 3C working group to consider.  But until then
I think we should stick to the existing interface.