spu_create — create a new spu context
#include <sys/types.h> #include <sys/spu.h>
int spu_create( |
const char *pathname, |
| int flags, | |
mode_t mode); |
int spu_create( |
const char *pathname, |
| int flags, | |
| mode_t mode, | |
int neighbor_fd); |
The spu_create() system call
is used on PowerPC machines that implement the Cell Broadband
Engine Architecture in order to access Synergistic Processor
Units (SPUs). It creates a new logical context for an SPU in
pathname and returns
a file descriptor associated with it. pathname must refer to a
nonexistent directory in the mount point of the SPU file
system (spufs). If
spu_create() is successful, a
directory is created at pathname and it is populated
with the files described in spufs(7).
When a context is created, the returned file descriptor
can only be passed to spu_run(2), used as the
dirfd argument to
the *at family of
system calls (e.g., openat(2)), or closed;
other operations are not defined. A logical SPU context is
destroyed (along with all files created within the context's
pathname directory)
once the last reference to the context has gone; this usually
occurs when the file descriptor returned by spu_create() is closed.
The flags argument
can be zero or any bitwise OR-ed combination of the following
constants:
SPU_CREATE_EVENTS_ENABLEDRather than using signals for reporting DMA errors,
use the event
argument to spu_run(2).
SPU_CREATE_GANGCreate an SPU gang instead of a context. (A gang is a group of SPU contexts that are functionally related to each other and which share common scheduling parameters — priority and policy. In the future, gang scheduling may be implemented causing the group to be switched in and out as a single unit.)
A new directory will be created at the location
specified by the pathname argument. This
gang may be used to hold other SPU contexts, by
providing a pathname that is within the gang directory
to further calls to spu_create().
SPU_CREATE_NOSCHEDCreate a context that is not affected by the SPU scheduler. Once the context is run, it will not be scheduled out until it is destroyed by the creating process.
Because the context cannot be removed from the SPU,
some functionality is disabled for SPU_CREATE_NOSCHED contexts. Only a
subset of the files will be available in this context
directory in spufs.
Additionally, SPU_CREATE_NOSCHED contexts cannot
dump a core file when crashing.
Creating SPU_CREATE_NOSCHED contexts requires
the CAP_SYS_NICE
capability.
SPU_CREATE_ISOLATECreate an isolated SPU context. Isolated contexts are protected from some PPE (PowerPC Processing Element) operations, such as access to the SPU local store and the NPC register.
Creating SPU_CREATE_ISOLATE contexts also
requires the SPU_CREATE_NOSCHED flag.
SPU_CREATE_AFFINITY_SPUCreate a context with affinity to another SPU
context. This affinity information is used within the
SPU scheduling algorithm. Using this flag requires that
a file descriptor referring to the other SPU context be
passed in the neighbor_fd argument.
SPU_CREATE_AFFINITY_MEMCreate a context with affinity to system memory. This affinity information is used within the SPU scheduling algorithm.
The mode argument
(minus any bits set in the process's umask(2)) specifies the
permissions used for creating the new directory in
spufs. See stat(2) for a full list of
the possible mode
values.
On success, spu_create()
returns a new file descriptor. On error, −1 is
returned, and errno is set to
one of the error codes listed below.
The current user does not have write access to the spufs(7) mount point.
An SPU context already exists at the given path name.
pathname is
not a valid string pointer in the calling process's
address space.
pathname is
not a directory in the spufs(7) mount point,
or invalid flags have been provided.
Too many symbolic links were found while resolving
pathname.
The process has reached its maximum open files limit.
pathname is
too long.
The system has reached the global open files limit.
An isolated context was requested, but the hardware does not support SPU isolation.
Part of pathname could not be
resolved.
The kernel could not allocate all resources required.
There are not enough SPU resources available to create a new context or the user-specific limit for the number of SPU contexts has been reached.
The functionality is not provided by the current system, because either the hardware does not provide SPUs or the spufs module is not loaded.
A part of pathname is not a
directory.
The SPU_CREATE_NOSCHED
flag has been given, but the user does not have the
CAP_SYS_NICE
capability.
pathname must
point to a location beneath the mount point of spufs. By convention, it gets mounted in
/spu.
This call is Linux-specific and only implemented on the PowerPC architecture. Programs using this system call are not portable.
Glibc does not provide a wrapper for this system call;
call it using syscall(2). Note however,
that spu_create() is meant to
be used from libraries that implement a more abstract
interface to SPUs, not to be used from regular applications.
See http://www.bsc.es/projects/deepcomputing/linuxoncell/
for the recommended libraries.
This page is part of release 3.24 of the Linux man-pages project. A
description of the project, and information about reporting
bugs, can be found at
http://www.kernel.org/doc/man-pages/.
|
Copyright (c) International Business Machines Corp., 2006 This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA HISTORY: 2005-09-28, created by Arnd Bergmann <arndbde.ibm.com> 2006-06-16, revised by Eduardo M. Fleury <efleurybr.ibm.com> 2007-07-10, some polishing by mtk 2007-09-28, updates for newer kernels by Jeremy Kerr <jkozlabs.org> |