[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

packaging/support for a pseudofilesystem

hey folks,

i'm looking to introduce better support for various aspects of using
the ps3 with debian, and amongst other things this includes better support
for spufs, the kernel-based pseudofilesystem for interacting with the
SPU's on ps3's cell processor.

typically (i.e. in documentation and other distributions) spufs is mounted
at /spu, and is initially empty.  posix filesystem operations are then
used to manipulate/interact in different ways with the spu's and the programs
that are running on them.  i won't get into the details here, but for
those interested more info can be found here:


so this brings up some questions:

- is /spu acceptable?  

- would setting up /spu be better done as part of:
 - an install task, which creates an entry in fstab
 - part of the standard mounting/startup scripts
 - an installable spufs support package
ideally there should also be a spu user, or at least group, to control certain
aspects of access to this fs.  this should probably be a "default" user group,
similar to cdrom/audio/etc.

- is there a policy-compliant way to muck with adduser settings wrt this?
- is it different if done by a udeb?
- should i request a new static uid/gid for this and ask adduser to add it
  as default on the powerpc/ppc64 archs?
- should i just do some dpkg-reconfigurable debconf stuff to control who's
  in the group (and have it default to users with uid > 1000)?

currently, after thinking for a bit about it, my inclination is that

- /spu is okay.  while not condoned by the FHS, neither is /sys which
  serves a similar pseudofilesystem usage.
- an spufs-support package
- either a static uid/gid and adduser modification, or the debconf based




Attachment: signature.asc
Description: Digital signature

Reply to: