| Arnd Bergmann | 67207b9 | 2005-11-15 15:53:48 -0500 | [diff] [blame] | 1 | SPUFS(2)                   Linux Programmer's Manual                  SPUFS(2) | 
 | 2 |  | 
 | 3 |  | 
 | 4 |  | 
 | 5 | NAME | 
 | 6 |        spufs - the SPU file system | 
 | 7 |  | 
 | 8 |  | 
 | 9 | DESCRIPTION | 
 | 10 |        The SPU file system is used on PowerPC machines that implement the Cell | 
 | 11 |        Broadband Engine Architecture in order to access Synergistic  Processor | 
 | 12 |        Units (SPUs). | 
 | 13 |  | 
 | 14 |        The file system provides a name space similar to posix shared memory or | 
 | 15 |        message queues. Users that have write permissions on  the  file  system | 
 | 16 |        can use spu_create(2) to establish SPU contexts in the spufs root. | 
 | 17 |  | 
 | 18 |        Every SPU context is represented by a directory containing a predefined | 
 | 19 |        set of files. These files can be used for manipulating the state of the | 
 | 20 |        logical SPU. Users can change permissions on those files, but not actu- | 
 | 21 |        ally add or remove files. | 
 | 22 |  | 
 | 23 |  | 
 | 24 | MOUNT OPTIONS | 
 | 25 |        uid=<uid> | 
 | 26 |               set the user owning the mount point, the default is 0 (root). | 
 | 27 |  | 
 | 28 |        gid=<gid> | 
 | 29 |               set the group owning the mount point, the default is 0 (root). | 
 | 30 |  | 
 | 31 |  | 
 | 32 | FILES | 
 | 33 |        The files in spufs mostly follow the standard behavior for regular sys- | 
 | 34 |        tem  calls like read(2) or write(2), but often support only a subset of | 
 | 35 |        the operations supported on regular file systems. This list details the | 
 | 36 |        supported  operations  and  the  deviations  from  the behaviour in the | 
 | 37 |        respective man pages. | 
 | 38 |  | 
 | 39 |        All files that support the read(2) operation also support readv(2)  and | 
 | 40 |        all  files  that support the write(2) operation also support writev(2). | 
 | 41 |        All files support the access(2) and stat(2) family of  operations,  but | 
 | 42 |        only  the  st_mode,  st_nlink,  st_uid and st_gid fields of struct stat | 
 | 43 |        contain reliable information. | 
 | 44 |  | 
 | 45 |        All files support the chmod(2)/fchmod(2) and chown(2)/fchown(2)  opera- | 
 | 46 |        tions,  but  will  not be able to grant permissions that contradict the | 
 | 47 |        possible operations, e.g. read access on the wbox file. | 
 | 48 |  | 
 | 49 |        The current set of files is: | 
 | 50 |  | 
 | 51 |  | 
 | 52 |    /mem | 
 | 53 |        the contents of the local storage memory  of  the  SPU.   This  can  be | 
 | 54 |        accessed  like  a regular shared memory file and contains both code and | 
 | 55 |        data in the address space of the SPU.  The possible  operations  on  an | 
 | 56 |        open mem file are: | 
 | 57 |  | 
 | 58 |        read(2), pread(2), write(2), pwrite(2), lseek(2) | 
 | 59 |               These  operate  as  documented, with the exception that seek(2), | 
 | 60 |               write(2) and pwrite(2) are not supported beyond the end  of  the | 
 | 61 |               file. The file size is the size of the local storage of the SPU, | 
 | 62 |               which normally is 256 kilobytes. | 
 | 63 |  | 
 | 64 |        mmap(2) | 
 | 65 |               Mapping mem into the process address space gives access  to  the | 
 | 66 |               SPU  local  storage  within  the  process  address  space.  Only | 
 | 67 |               MAP_SHARED mappings are allowed. | 
 | 68 |  | 
 | 69 |  | 
 | 70 |    /mbox | 
 | 71 |        The first SPU to CPU communication mailbox. This file is read-only  and | 
 | 72 |        can  be  read  in  units of 32 bits.  The file can only be used in non- | 
 | 73 |        blocking mode and it even poll() will not block on  it.   The  possible | 
 | 74 |        operations on an open mbox file are: | 
 | 75 |  | 
 | 76 |        read(2) | 
 | 77 |               If  a  count smaller than four is requested, read returns -1 and | 
 | 78 |               sets errno to EINVAL.  If there is no data available in the mail | 
 | 79 |               box,  the  return  value  is set to -1 and errno becomes EAGAIN. | 
 | 80 |               When data has been read successfully, four bytes are  placed  in | 
 | 81 |               the data buffer and the value four is returned. | 
 | 82 |  | 
 | 83 |  | 
 | 84 |    /ibox | 
 | 85 |        The  second  SPU  to CPU communication mailbox. This file is similar to | 
 | 86 |        the first mailbox file, but can be read in blocking I/O mode,  and  the | 
| Matt LaPlante | a2ffd27 | 2006-10-03 22:49:15 +0200 | [diff] [blame] | 87 |        poll  family of system calls can be used to wait for it.  The  possible | 
| Arnd Bergmann | 67207b9 | 2005-11-15 15:53:48 -0500 | [diff] [blame] | 88 |        operations on an open ibox file are: | 
 | 89 |  | 
 | 90 |        read(2) | 
 | 91 |               If a count smaller than four is requested, read returns  -1  and | 
 | 92 |               sets errno to EINVAL.  If there is no data available in the mail | 
 | 93 |               box and the file descriptor has been opened with O_NONBLOCK, the | 
 | 94 |               return value is set to -1 and errno becomes EAGAIN. | 
 | 95 |  | 
 | 96 |               If  there  is  no  data  available  in the mail box and the file | 
 | 97 |               descriptor has been opened without  O_NONBLOCK,  the  call  will | 
 | 98 |               block  until  the  SPU  writes to its interrupt mailbox channel. | 
 | 99 |               When data has been read successfully, four bytes are  placed  in | 
 | 100 |               the data buffer and the value four is returned. | 
 | 101 |  | 
 | 102 |        poll(2) | 
 | 103 |               Poll  on  the  ibox  file returns (POLLIN | POLLRDNORM) whenever | 
 | 104 |               data is available for reading. | 
 | 105 |  | 
 | 106 |  | 
 | 107 |    /wbox | 
| Paolo Ornati | 670e9f3 | 2006-10-03 22:57:56 +0200 | [diff] [blame] | 108 |        The CPU to SPU communation mailbox. It is write-only and can be written | 
| Arnd Bergmann | 67207b9 | 2005-11-15 15:53:48 -0500 | [diff] [blame] | 109 |        in  units  of  32  bits. If the mailbox is full, write() will block and | 
 | 110 |        poll can be used to wait for it becoming  empty  again.   The  possible | 
 | 111 |        operations  on  an open wbox file are: write(2) If a count smaller than | 
 | 112 |        four is requested, write returns -1 and sets errno to EINVAL.  If there | 
 | 113 |        is  no space available in the mail box and the file descriptor has been | 
 | 114 |        opened with O_NONBLOCK, the return value is set to -1 and errno becomes | 
 | 115 |        EAGAIN. | 
 | 116 |  | 
 | 117 |        If  there is no space available in the mail box and the file descriptor | 
 | 118 |        has been opened without O_NONBLOCK, the call will block until  the  SPU | 
 | 119 |        reads  from  its PPE mailbox channel.  When data has been read success- | 
 | 120 |        fully, four bytes are placed in the data buffer and the value  four  is | 
 | 121 |        returned. | 
 | 122 |  | 
 | 123 |        poll(2) | 
 | 124 |               Poll  on  the  ibox file returns (POLLOUT | POLLWRNORM) whenever | 
 | 125 |               space is available for writing. | 
 | 126 |  | 
 | 127 |  | 
 | 128 |    /mbox_stat | 
 | 129 |    /ibox_stat | 
 | 130 |    /wbox_stat | 
 | 131 |        Read-only files that contain the length of the current queue, i.e.  how | 
 | 132 |        many  words  can  be  read  from  mbox or ibox or how many words can be | 
 | 133 |        written to wbox without blocking.  The files can be read only in 4-byte | 
 | 134 |        units  and  return  a  big-endian  binary integer number.  The possible | 
 | 135 |        operations on an open *box_stat file are: | 
 | 136 |  | 
 | 137 |        read(2) | 
 | 138 |               If a count smaller than four is requested, read returns  -1  and | 
 | 139 |               sets errno to EINVAL.  Otherwise, a four byte value is placed in | 
 | 140 |               the data buffer, containing the number of elements that  can  be | 
 | 141 |               read  from  (for  mbox_stat  and  ibox_stat)  or written to (for | 
 | 142 |               wbox_stat) the respective mail box without blocking or resulting | 
 | 143 |               in EAGAIN. | 
 | 144 |  | 
 | 145 |  | 
 | 146 |    /npc | 
 | 147 |    /decr | 
 | 148 |    /decr_status | 
 | 149 |    /spu_tag_mask | 
 | 150 |    /event_mask | 
 | 151 |    /srr0 | 
 | 152 |        Internal  registers  of  the SPU. The representation is an ASCII string | 
 | 153 |        with the numeric value of the next instruction to  be  executed.  These | 
 | 154 |        can  be  used in read/write mode for debugging, but normal operation of | 
 | 155 |        programs should not rely on them because access to any of  them  except | 
 | 156 |        npc requires an SPU context save and is therefore very inefficient. | 
 | 157 |  | 
 | 158 |        The contents of these files are: | 
 | 159 |  | 
 | 160 |        npc                 Next Program Counter | 
 | 161 |  | 
 | 162 |        decr                SPU Decrementer | 
 | 163 |  | 
 | 164 |        decr_status         Decrementer Status | 
 | 165 |  | 
 | 166 |        spu_tag_mask        MFC tag mask for SPU DMA | 
 | 167 |  | 
 | 168 |        event_mask          Event mask for SPU interrupts | 
 | 169 |  | 
 | 170 |        srr0                Interrupt Return address register | 
 | 171 |  | 
 | 172 |  | 
 | 173 |        The   possible   operations   on   an   open  npc,  decr,  decr_status, | 
 | 174 |        spu_tag_mask, event_mask or srr0 file are: | 
 | 175 |  | 
 | 176 |        read(2) | 
 | 177 |               When the count supplied to the read call  is  shorter  than  the | 
 | 178 |               required  length for the pointer value plus a newline character, | 
 | 179 |               subsequent reads from the same file descriptor  will  result  in | 
 | 180 |               completing  the string, regardless of changes to the register by | 
 | 181 |               a running SPU task.  When a complete string has been  read,  all | 
 | 182 |               subsequent read operations will return zero bytes and a new file | 
 | 183 |               descriptor needs to be opened to read the value again. | 
 | 184 |  | 
 | 185 |        write(2) | 
 | 186 |               A write operation on the file results in setting the register to | 
 | 187 |               the  value  given  in  the string. The string is parsed from the | 
 | 188 |               beginning to the first non-numeric character or the end  of  the | 
 | 189 |               buffer.  Subsequent writes to the same file descriptor overwrite | 
 | 190 |               the previous setting. | 
 | 191 |  | 
 | 192 |  | 
 | 193 |    /fpcr | 
 | 194 |        This file gives access to the Floating Point Status and Control  Regis- | 
 | 195 |        ter as a four byte long file. The operations on the fpcr file are: | 
 | 196 |  | 
 | 197 |        read(2) | 
 | 198 |               If  a  count smaller than four is requested, read returns -1 and | 
 | 199 |               sets errno to EINVAL.  Otherwise, a four byte value is placed in | 
 | 200 |               the data buffer, containing the current value of the fpcr regis- | 
 | 201 |               ter. | 
 | 202 |  | 
 | 203 |        write(2) | 
 | 204 |               If a count smaller than four is requested, write returns -1  and | 
 | 205 |               sets  errno  to  EINVAL.  Otherwise, a four byte value is copied | 
 | 206 |               from the data buffer, updating the value of the fpcr register. | 
 | 207 |  | 
 | 208 |  | 
 | 209 |    /signal1 | 
 | 210 |    /signal2 | 
 | 211 |        The two signal notification channels of an SPU.  These  are  read-write | 
 | 212 |        files  that  operate  on  a 32 bit word.  Writing to one of these files | 
| Matt LaPlante | 4ae0edc | 2006-11-30 04:58:40 +0100 | [diff] [blame] | 213 |        triggers an interrupt on the SPU.  The  value  written  to  the  signal | 
| Arnd Bergmann | 67207b9 | 2005-11-15 15:53:48 -0500 | [diff] [blame] | 214 |        files can be read from the SPU through a channel read or from host user | 
 | 215 |        space through the file.  After the value has been read by the  SPU,  it | 
 | 216 |        is  reset  to zero.  The possible operations on an open signal1 or sig- | 
 | 217 |        nal2 file are: | 
 | 218 |  | 
 | 219 |        read(2) | 
 | 220 |               If a count smaller than four is requested, read returns  -1  and | 
 | 221 |               sets errno to EINVAL.  Otherwise, a four byte value is placed in | 
 | 222 |               the data buffer, containing the current value of  the  specified | 
 | 223 |               signal notification register. | 
 | 224 |  | 
 | 225 |        write(2) | 
 | 226 |               If  a count smaller than four is requested, write returns -1 and | 
 | 227 |               sets errno to EINVAL.  Otherwise, a four byte  value  is  copied | 
 | 228 |               from the data buffer, updating the value of the specified signal | 
 | 229 |               notification register.  The signal  notification  register  will | 
 | 230 |               either be replaced with the input data or will be updated to the | 
 | 231 |               bitwise OR or the old value and the input data, depending on the | 
 | 232 |               contents  of  the  signal1_type,  or  signal2_type respectively, | 
 | 233 |               file. | 
 | 234 |  | 
 | 235 |  | 
 | 236 |    /signal1_type | 
 | 237 |    /signal2_type | 
 | 238 |        These two files change the behavior of the signal1 and signal2  notifi- | 
 | 239 |        cation  files.  The  contain  a numerical ASCII string which is read as | 
 | 240 |        either "1" or "0".  In mode 0 (overwrite), the  hardware  replaces  the | 
 | 241 |        contents of the signal channel with the data that is written to it.  in | 
 | 242 |        mode 1 (logical OR), the hardware accumulates the bits that are  subse- | 
 | 243 |        quently written to it.  The possible operations on an open signal1_type | 
 | 244 |        or signal2_type file are: | 
 | 245 |  | 
 | 246 |        read(2) | 
 | 247 |               When the count supplied to the read call  is  shorter  than  the | 
 | 248 |               required  length  for the digit plus a newline character, subse- | 
 | 249 |               quent reads from the same file descriptor will  result  in  com- | 
 | 250 |               pleting  the  string.  When a complete string has been read, all | 
 | 251 |               subsequent read operations will return zero bytes and a new file | 
 | 252 |               descriptor needs to be opened to read the value again. | 
 | 253 |  | 
 | 254 |        write(2) | 
 | 255 |               A write operation on the file results in setting the register to | 
 | 256 |               the value given in the string. The string  is  parsed  from  the | 
 | 257 |               beginning  to  the first non-numeric character or the end of the | 
 | 258 |               buffer.  Subsequent writes to the same file descriptor overwrite | 
 | 259 |               the previous setting. | 
 | 260 |  | 
 | 261 |  | 
 | 262 | EXAMPLES | 
 | 263 |        /etc/fstab entry | 
 | 264 |               none      /spu      spufs     gid=spu   0    0 | 
 | 265 |  | 
 | 266 |  | 
 | 267 | AUTHORS | 
 | 268 |        Arnd  Bergmann  <arndb@de.ibm.com>,  Mark  Nutter <mnutter@us.ibm.com>, | 
 | 269 |        Ulrich Weigand <Ulrich.Weigand@de.ibm.com> | 
 | 270 |  | 
 | 271 | SEE ALSO | 
 | 272 |        capabilities(7), close(2), spu_create(2), spu_run(2), spufs(7) | 
 | 273 |  | 
 | 274 |  | 
 | 275 |  | 
 | 276 | Linux                             2005-09-28                          SPUFS(2) | 
 | 277 |  | 
 | 278 | ------------------------------------------------------------------------------ | 
 | 279 |  | 
 | 280 | SPU_RUN(2)                 Linux Programmer's Manual                SPU_RUN(2) | 
 | 281 |  | 
 | 282 |  | 
 | 283 |  | 
 | 284 | NAME | 
 | 285 |        spu_run - execute an spu context | 
 | 286 |  | 
 | 287 |  | 
 | 288 | SYNOPSIS | 
 | 289 |        #include <sys/spu.h> | 
 | 290 |  | 
 | 291 |        int spu_run(int fd, unsigned int *npc, unsigned int *event); | 
 | 292 |  | 
 | 293 | DESCRIPTION | 
 | 294 |        The  spu_run system call is used on PowerPC machines that implement the | 
 | 295 |        Cell Broadband Engine Architecture in order to access Synergistic  Pro- | 
 | 296 |        cessor  Units  (SPUs).  It  uses the fd that was returned from spu_cre- | 
 | 297 |        ate(2) to address a specific SPU context. When the context gets  sched- | 
 | 298 |        uled  to a physical SPU, it starts execution at the instruction pointer | 
 | 299 |        passed in npc. | 
 | 300 |  | 
 | 301 |        Execution of SPU code happens synchronously, meaning that spu_run  does | 
 | 302 |        not  return  while the SPU is still running. If there is a need to exe- | 
 | 303 |        cute SPU code in parallel with other code on either  the  main  CPU  or | 
 | 304 |        other  SPUs,  you  need to create a new thread of execution first, e.g. | 
 | 305 |        using the pthread_create(3) call. | 
 | 306 |  | 
 | 307 |        When spu_run returns, the current value of the SPU instruction  pointer | 
 | 308 |        is  written back to npc, so you can call spu_run again without updating | 
 | 309 |        the pointers. | 
 | 310 |  | 
 | 311 |        event can be a NULL pointer or point to an extended  status  code  that | 
 | 312 |        gets  filled  when spu_run returns. It can be one of the following con- | 
 | 313 |        stants: | 
 | 314 |  | 
 | 315 |        SPE_EVENT_DMA_ALIGNMENT | 
 | 316 |               A DMA alignment error | 
 | 317 |  | 
 | 318 |        SPE_EVENT_SPE_DATA_SEGMENT | 
 | 319 |               A DMA segmentation error | 
 | 320 |  | 
 | 321 |        SPE_EVENT_SPE_DATA_STORAGE | 
 | 322 |               A DMA storage error | 
 | 323 |  | 
 | 324 |        If NULL is passed as the event argument, these errors will result in  a | 
 | 325 |        signal delivered to the calling process. | 
 | 326 |  | 
 | 327 | RETURN VALUE | 
 | 328 |        spu_run  returns the value of the spu_status register or -1 to indicate | 
 | 329 |        an error and set errno to one of the error  codes  listed  below.   The | 
 | 330 |        spu_status  register  value  contains  a  bit  mask of status codes and | 
 | 331 |        optionally a 14 bit code returned from the stop-and-signal  instruction | 
 | 332 |        on the SPU. The bit masks for the status codes are: | 
 | 333 |  | 
 | 334 |        0x02   SPU was stopped by stop-and-signal. | 
 | 335 |  | 
 | 336 |        0x04   SPU was stopped by halt. | 
 | 337 |  | 
 | 338 |        0x08   SPU is waiting for a channel. | 
 | 339 |  | 
 | 340 |        0x10   SPU is in single-step mode. | 
 | 341 |  | 
 | 342 |        0x20   SPU has tried to execute an invalid instruction. | 
 | 343 |  | 
 | 344 |        0x40   SPU has tried to access an invalid channel. | 
 | 345 |  | 
 | 346 |        0x3fff0000 | 
 | 347 |               The  bits  masked with this value contain the code returned from | 
 | 348 |               stop-and-signal. | 
 | 349 |  | 
 | 350 |        There are always one or more of the lower eight bits set  or  an  error | 
 | 351 |        code is returned from spu_run. | 
 | 352 |  | 
 | 353 | ERRORS | 
 | 354 |        EAGAIN or EWOULDBLOCK | 
 | 355 |               fd is in non-blocking mode and spu_run would block. | 
 | 356 |  | 
 | 357 |        EBADF  fd is not a valid file descriptor. | 
 | 358 |  | 
 | 359 |        EFAULT npc is not a valid pointer or status is neither NULL nor a valid | 
 | 360 |               pointer. | 
 | 361 |  | 
| Matt LaPlante | 992caac | 2006-10-03 22:52:05 +0200 | [diff] [blame] | 362 |        EINTR  A signal occurred while spu_run was in progress.  The npc  value | 
| Arnd Bergmann | 67207b9 | 2005-11-15 15:53:48 -0500 | [diff] [blame] | 363 |               has  been updated to the new program counter value if necessary. | 
 | 364 |  | 
 | 365 |        EINVAL fd is not a file descriptor returned from spu_create(2). | 
 | 366 |  | 
 | 367 |        ENOMEM Insufficient memory was available to handle a page fault result- | 
 | 368 |               ing from an MFC direct memory access. | 
 | 369 |  | 
 | 370 |        ENOSYS the functionality is not provided by the current system, because | 
 | 371 |               either the hardware does not provide SPUs or the spufs module is | 
 | 372 |               not loaded. | 
 | 373 |  | 
 | 374 |  | 
 | 375 | NOTES | 
 | 376 |        spu_run  is  meant  to  be  used  from  libraries that implement a more | 
 | 377 |        abstract interface to SPUs, not to be used from  regular  applications. | 
 | 378 |        See  http://www.bsc.es/projects/deepcomputing/linuxoncell/ for the rec- | 
 | 379 |        ommended libraries. | 
 | 380 |  | 
 | 381 |  | 
 | 382 | CONFORMING TO | 
 | 383 |        This call is Linux specific and only implemented by the ppc64 architec- | 
 | 384 |        ture. Programs using this system call are not portable. | 
 | 385 |  | 
 | 386 |  | 
 | 387 | BUGS | 
 | 388 |        The code does not yet fully implement all features lined out here. | 
 | 389 |  | 
 | 390 |  | 
 | 391 | AUTHOR | 
 | 392 |        Arnd Bergmann <arndb@de.ibm.com> | 
 | 393 |  | 
 | 394 | SEE ALSO | 
 | 395 |        capabilities(7), close(2), spu_create(2), spufs(7) | 
 | 396 |  | 
 | 397 |  | 
 | 398 |  | 
 | 399 | Linux                             2005-09-28                        SPU_RUN(2) | 
 | 400 |  | 
 | 401 | ------------------------------------------------------------------------------ | 
 | 402 |  | 
 | 403 | SPU_CREATE(2)              Linux Programmer's Manual             SPU_CREATE(2) | 
 | 404 |  | 
 | 405 |  | 
 | 406 |  | 
 | 407 | NAME | 
 | 408 |        spu_create - create a new spu context | 
 | 409 |  | 
 | 410 |  | 
 | 411 | SYNOPSIS | 
 | 412 |        #include <sys/types.h> | 
 | 413 |        #include <sys/spu.h> | 
 | 414 |  | 
 | 415 |        int spu_create(const char *pathname, int flags, mode_t mode); | 
 | 416 |  | 
 | 417 | DESCRIPTION | 
 | 418 |        The  spu_create  system call is used on PowerPC machines that implement | 
 | 419 |        the Cell Broadband Engine Architecture in order to  access  Synergistic | 
 | 420 |        Processor  Units (SPUs). It creates a new logical context for an SPU in | 
 | 421 |        pathname and returns a handle to associated  with  it.   pathname  must | 
 | 422 |        point  to  a  non-existing directory in the mount point of the SPU file | 
 | 423 |        system (spufs).  When spu_create is successful, a directory  gets  cre- | 
 | 424 |        ated on pathname and it is populated with files. | 
 | 425 |  | 
 | 426 |        The  returned  file  handle can only be passed to spu_run(2) or closed, | 
 | 427 |        other operations are not defined on it. When it is closed, all  associ- | 
 | 428 |        ated  directory entries in spufs are removed. When the last file handle | 
 | 429 |        pointing either inside  of  the  context  directory  or  to  this  file | 
 | 430 |        descriptor is closed, the logical SPU context is destroyed. | 
 | 431 |  | 
 | 432 |        The  parameter flags can be zero or any bitwise or'd combination of the | 
 | 433 |        following constants: | 
 | 434 |  | 
 | 435 |        SPU_RAWIO | 
 | 436 |               Allow mapping of some of the hardware registers of the SPU  into | 
 | 437 |               user space. This flag requires the CAP_SYS_RAWIO capability, see | 
 | 438 |               capabilities(7). | 
 | 439 |  | 
 | 440 |        The mode parameter specifies the permissions used for creating the  new | 
 | 441 |        directory  in  spufs.   mode is modified with the user's umask(2) value | 
 | 442 |        and then used for both the directory and the files contained in it. The | 
 | 443 |        file permissions mask out some more bits of mode because they typically | 
 | 444 |        support only read or write access. See stat(2) for a full list  of  the | 
 | 445 |        possible mode values. | 
 | 446 |  | 
 | 447 |  | 
 | 448 | RETURN VALUE | 
 | 449 |        spu_create  returns a new file descriptor. It may return -1 to indicate | 
 | 450 |        an error condition and set errno to  one  of  the  error  codes  listed | 
 | 451 |        below. | 
 | 452 |  | 
 | 453 |  | 
 | 454 | ERRORS | 
 | 455 |        EACCESS | 
 | 456 |               The  current  user does not have write access on the spufs mount | 
 | 457 |               point. | 
 | 458 |  | 
 | 459 |        EEXIST An SPU context already exists at the given path name. | 
 | 460 |  | 
 | 461 |        EFAULT pathname is not a valid string pointer in  the  current  address | 
 | 462 |               space. | 
 | 463 |  | 
 | 464 |        EINVAL pathname is not a directory in the spufs mount point. | 
 | 465 |  | 
 | 466 |        ELOOP  Too many symlinks were found while resolving pathname. | 
 | 467 |  | 
 | 468 |        EMFILE The process has reached its maximum open file limit. | 
 | 469 |  | 
 | 470 |        ENAMETOOLONG | 
 | 471 |               pathname was too long. | 
 | 472 |  | 
 | 473 |        ENFILE The system has reached the global open file limit. | 
 | 474 |  | 
 | 475 |        ENOENT Part of pathname could not be resolved. | 
 | 476 |  | 
 | 477 |        ENOMEM The kernel could not allocate all resources required. | 
 | 478 |  | 
 | 479 |        ENOSPC There  are  not  enough  SPU resources available to create a new | 
 | 480 |               context or the user specific limit for the number  of  SPU  con- | 
 | 481 |               texts has been reached. | 
 | 482 |  | 
 | 483 |        ENOSYS the functionality is not provided by the current system, because | 
 | 484 |               either the hardware does not provide SPUs or the spufs module is | 
 | 485 |               not loaded. | 
 | 486 |  | 
 | 487 |        ENOTDIR | 
 | 488 |               A part of pathname is not a directory. | 
 | 489 |  | 
 | 490 |  | 
 | 491 |  | 
 | 492 | NOTES | 
 | 493 |        spu_create  is  meant  to  be used from libraries that implement a more | 
 | 494 |        abstract interface to SPUs, not to be used from  regular  applications. | 
 | 495 |        See  http://www.bsc.es/projects/deepcomputing/linuxoncell/ for the rec- | 
 | 496 |        ommended libraries. | 
 | 497 |  | 
 | 498 |  | 
 | 499 | FILES | 
 | 500 |        pathname must point to a location beneath the mount point of spufs.  By | 
 | 501 |        convention, it gets mounted in /spu. | 
 | 502 |  | 
 | 503 |  | 
 | 504 | CONFORMING TO | 
 | 505 |        This call is Linux specific and only implemented by the ppc64 architec- | 
 | 506 |        ture. Programs using this system call are not portable. | 
 | 507 |  | 
 | 508 |  | 
 | 509 | BUGS | 
 | 510 |        The code does not yet fully implement all features lined out here. | 
 | 511 |  | 
 | 512 |  | 
 | 513 | AUTHOR | 
 | 514 |        Arnd Bergmann <arndb@de.ibm.com> | 
 | 515 |  | 
 | 516 | SEE ALSO | 
 | 517 |        capabilities(7), close(2), spu_run(2), spufs(7) | 
 | 518 |  | 
 | 519 |  | 
 | 520 |  | 
 | 521 | Linux                             2005-09-28                     SPU_CREATE(2) |