Provided by: manpages-fr_4.27.0-1_all 

NOM
spufs - Système de fichiers SPU
DESCRIPTION
Le système de fichiers SPU est utilisé sur les machines PowerPC qui utilisent l'architecture Cell
Broadband Engine Architecture pour accéder aux SPU (« Synergistic Processor Units »).
Le système de fichiers fournit un espace de noms similaire à la mémoire partagée ou aux queues de
messages POSIX. Les utilisateurs qui ont la permission d'écrire sur le système de fichiers peuvent
utiliser spu_create(2) pour établir des contextes SPU dans le répertoire racine du spufs.
Chaque contexte SPU est représenté par un répertoire contenant un jeu de fichiers prédéfinis. Ces
fichiers peuvent être utilisés pour manipuler l'état du SPU logique. Les utilisateurs peuvent changer les
permissions des fichiers, mais ne peuvent ni en ajouter ni en supprimer.
Options de montage
uid=<uid>
Définit l'utilisateur propriétaire du point de montage ; 0 par défaut (root).
gid=<gid>
Définit le groupe propriétaire du point de montage ; 0 par défaut (root).
mode=<mode>
Définir le mode du répertoire de plus haut niveau du spufs sous la forme d'une chaîne de valeur
octale. La valeur par défaut est 0775.
Fichiers
Les fichiers du spufs se comportent majoritairement de façon standard pour les appels système comme
read(2) ou write(2), mais ne gèrent souvent qu'une fraction des opérations permises par les systèmes de
fichiers normaux. Cette liste détaille les opérations gérées et les dérogations par rapport aux
comportements standards qui sont décrits dans les différentes pages de manuel.
Tous les fichiers qui gèrent l'opération read(2) gèrent également readv(2) et tous les fichiers qui
gèrent l'opération write(2) gèrent aussi writev(2). Tous les fichiers gèrent les familles d'opérations
access(2) stat(2), mais pour cette dernière famille, les seuls champs de la structure stat renvoyée qui
contiennent des informations fiables sont st_mode, st_nlink, st_uid et st_gid.
All files support the chmod(2)/ fchmod(2) and chown(2)/ fchown(2) operations, but will not be able to
grant permissions that contradict the possible operations (e.g., read access on the wbox file).
Le jeux actuel de fichiers est :
/capabilities
Contient une chaîne représentant les capacités, séparées par des virgules, de ce contexte SPU. Les
capacités possibles sont :
sched Ce contexte peut être ordonnancé.
step Ce contexte peut être exécuté en mode pas-à-pas, pour débogage.
De nouveaux attributs de capacités pourront être ajoutés dans le futur.
/mem Le contenu de la mémoire de stockage locale du SPU. On peut y accéder comme à un fichier de
mémoire partagé standard et il contient à la fois le code et les données de l'espace d'adressage
du SPU. Les opérations possibles sur un fichier mem ouvert sont :
read(2)
pread(2)
write(2)
pwrite(2)
lseek(2)
Elles opèrent normalement, à l'exception de lseek(2), write(2) et pwrite(2) qui ne sont pas
gérées en dehors des limites du fichier. La taille du fichier est la taille de l'espace de
stockage local du SPU, qui est normalement de 256 kilooctets.
mmap(2)
La projection de mem dans l'espace d'adressage du processus donne accès à l'espace de
stockage local du SPU depuis l'espace d'adressage du processus. Seules les projections
MAP_SHARED sont autorisées.
/regs Contient la sauvegarde des registres à vocation générale du contexte SPU. Ce fichier contient les
valeurs 128 bits de chaque registre, du registre 0 au registre 127, dans l'ordre. Cela permet de
consulter le contenu de ces registres à vocation générale à des fins de débogage.
La lecture ou l'écriture dans ce fichier nécessite que le contexte ne soit pas ordonnancé, aussi,
l'utilisation de ce fichier n'est pas recommandé lors de l'exécution normale d'un programme.
Le fichier regs n'existe pas pour les contextes créés avec l'attribut SPU_CREATE_NOSCHED.
/mbox La première boîte aux lettres pour la communication entre SPU et CPU. Ce fichier est en lecture
seule et peut être lu par unités de 4 octets. Le fichier peut uniquement être utilisé en mode non
bloquant - même poll(2) ne peut pas être utuilisé pour se bloquer sur ce fichier. La seule
opération possible sur un fichier mbox ouvert est :
read(2)
Si count est plus petit que quatre, read(2) renvoie -1 et positionne errno à EINVAL. S'il
n'y a pas de donnée disponible dans la boîte aux lettres (c'est-à-dire si le SPU n'a pas
envoyé de message dans la boîte aux lettres), la valeur de retour est -1 et errno est
positionnée à EAGAIN. Quand des données ont été lues avec succès, quatre octets sont placés
dans le tampon de données et la valeur renvoyée est quatre.
/ibox La deuxième boîte aux lettres pour la communication entre SPU et CPU. Ce fichier est similaire au
premier fichier de boîte aux lettres, mais peut être lu en mode bloquant, ainsi appeler read(2)
sur un fichier ibox ouvert bloquera tant que le SPU n'a pas écrit dans son canal boîte à lettres
(à moins que le fichier n'ait été ouvert avec O_NONBLOCK, voir ci-dessous). Également, poll(2) et
des appels système similaires peuvent être utilisés pour surveiller la présence de données dans la
boîte à lettres.
Les opérations possibles sur un fichier ibox ouvert sont :
read(2)
Si count est plus petit que quatre, read(2) renvoie -1 et positionne errno à EINVAL. S'il
n'y a pas de donnée disponible dans la boîte aux lettres et que le fichier a été ouvert
avec O_NONBLOCK, la valeur renvoyée est -1 et errno est positionnée à EAGAIN.
S'il n'y a pas de donnée disponible dans la boîte aux lettres et que le fichier a été
ouvert sans l'attribut O_NONBLOCK, l'appel bloquera jusqu'à ce que le SPU écrive dans son
canal d'interruption de la boîte aux lettres. Quand des données ont été lues avec succès,
quatre octets sont placés dans le tampon de données et la valeur quatre est renvoyée.
poll(2)
L'appel de poll(2) sur le fichier ibox renvoie (POLLIN | POLLRDNORM) quand des données sont
disponibles en lecture.
/wbox La boîte aux lettres pour la communication entre CPU et SPU. Elle est en écriture seulement et on
peut y écrire des données de 32 bits. Si la boîte aux lettres est pleine, write(2) bloque et
poll(2) peut être utilisé pour bloquer jusqu'à ce qu'il soit possible d'écrire dans la boîte aux
lettres. Les opérations possibles sur un fichier wbox ouvert sont :
write(2)
Si count est plus petit que quatre, write(2) renvoie -1 et positionne errno à EINVAL. S'il
n'y a pas d'espace disponible dans la boîte aux lettres et que le fichier a été ouvert avec
O_NONBLOCK, la valeur renvoyée est -1 et errno est positionnée à EAGAIN.
S'il n'y a pas d'espace disponible dans la boîte aux lettres et que le fichier a été ouvert
sans l'attribut O_NONBLOCK, l'appel bloque jusqu'à ce que le SPU lise dans le canal de sa
boîte aux lettres PPE (PowerPC Processing Element). Quand des données ont été écrites avec
succès, l'appel système renvoie 4 comme résultat de la fonction.
poll(2)
Un appel à poll(2) sur le fichier wbox renvoie (POLLOUT | POLLWRNORM) quand de l'espace est
disponible en écriture.
/mbox_stat
/ibox_stat
/wbox_stat
These are read-only files that contain the length of the current queue of each mailbox—that is,
how many words can be read from mbox or ibox or how many words can be written to wbox without
blocking. The files can be read only in four-byte units and return a big-endian binary integer
number. The only possible operation on an open *box_stat file is:
read(2)
Si count est plus petit que quatre, read(2) renvoie -1 et positionne errno à EINVAL. Sinon,
une valeur de quatre octets est placée dans le tampon de données. Cette valeur est le
nombre d'éléments qui peuvent être lus (pour mbox_stat et ibox_stat) ou écrits (pour
wbox_stat) dans les boîtes aux lettres respectives sans bloquer ou renvoyer une erreur
EAGAIN.
/npc
/decr
/decr_status
/spu_tag_mask
/event_mask
/event_status
/srr0
/lslr Les registres internes du SPU. Ces fichiers contiennent une chaîne de caractère ASCII représentant
la valeur hexadécimale du registre indiqué. Lire et écrire dans ces fichiers (hormis npc, voir
ci-dessous) nécessite que le contexte du SPU ne soit pas ordonnancé, aussi, les accès fréquents à
ces fichiers ne sont pas recommandés lors de l'exécution normale d'un programme.
Le contenu des fichiers est :
npc Compteur programme suivant - Valide uniquement lorsque le SPU est dans un état
arrêté.
decr Décrémenteur SPU
decr_status État du décrémenteur
spu_tag_mask Masque de attributs MFC pour le DMA SPU
event_mask Masque d'événements pour les interruptions SPU
event_status Nombre d'événements SPU en attente (lecture seule)
srr0 Registre contenant l'adresse de retour d'interruption
lslr Registre de limite de stokage local
Les opérations possibles sur ces fichiers sont :
read(2)
Lit la valeur actuelle du registre. Si la valeur du registre est plus grande que le tampon
passé à read(2), les lectures suivantes continueront à lire à partir du même tampon jusqu'à
ce que la fin du tampon soit atteinte.
Lorsqu'une chaîne complète a été lue, toutes les opérations de lecture suivantes renverront
zéro octet et il faudra ouvrir un nouveau descripteur de fichier pour lire une nouvelle
valeur.
write(2)
Un appel à write(2) sur le fichier définit le registre à la valeur fournie dans la chaîne.
La chaîne est analysée du début jusqu'au premier caractère non numérique ou jusqu'à la fin
du tampon. Les écritures suivantes sur le même descripteur de fichier remplaceront les
précédentes écritures.
Excepté pour le fichier npc, ces fichiers n'existent pas dans les contextes créés avec
l'attribut SPU_CREATE_NOSCHED.
/fpcr Ce fichier donne accès au registre d'état et de contrôle pour la virgule flottante (Floating Point
Status and Control Register, fcpr) comme un fichier binaire de quatre octets. Les opérations pour
le fichier fpcr sont :
read(2)
Si count est plus petit que quatre, read(2) renvoie -1 et positionne errno à EINVAL. Sinon,
une valeur de quatre octets est placée dans le tampon de données ; c'est la valeur actuelle
du registre fpcr.
write(2)
Si count est plus petit que quatre, write(2) renvoie -1 et positionne errno à EINVAL.
Sinon, une valeur de quatre octets est copiée depuis le tampon de données, mettant à jour
la valeur du registre fpcr.
/signal1
/signal2
Le fichier donne accès aux deux canaux de notification de signal d'un SPU. Ce sont des fichiers en
lecture et écriture qui utilisent des mots de quatre octets. Écrire dans un de ces fichiers
déclenche une interruption sur le SPU. La valeur écrite dans le fichier de signalisation peut être
lue depuis le SPU au travers d'un canal de lecture ou par l'espace utilisateur sur l'hôte grâce au
fichier. Les opérations possibles sur un fichier signal1 ou signal2 ouvert sont :
read(2)
Si count est plus petit que quatre, read(2) renvoie -1 et positionne errno à EINVAL. Sinon,
une valeur de quatre octets est placée dans le tampon de données ; c'est la valeur actuelle
du registre de notification du signal indiqué.
write(2)
Si count est plus petit que quatre, write(2) renvoie -1 et positionne errno à EINVAL.
Sinon, une valeur de quatre octets est copiée depuis le tampon de données et met à jour la
valeur du registre de notification du signal indiqué. Le registre de notification du signal
sera soit remplacé par les données fournies en entrée ou sera mis à jour par un OU bit à
bit de l'ancienne valeur et des données fournies en entrée, en fonction du contenu des
fichiers signal1_type ou signal2_type respectivement.
/signal1_type
/signal2_type
Ces deux fichiers changent le comportement des fichiers de notification signal1 et signal2. Ils
contiennent une chaîne ASCII numérique qui est lue comme "1" ou "0". Dans le mode 0
(remplacement), le matériel remplace le contenu du canal du signal avec la donnée qu'on y écrit.
Dans le mode 1 (OU logique), le matériel accumule les bits qui y sont écrits au fur et à mesure.
Les opérations possibles sur un fichier signal1_type ou signal2_type sont :
read(2)
Quand le paramètre count fourni à l'appel read(2) est plus petit que la longueur nécessaire
pour la valeur du chiffre (plus un caractère de fin de ligne), les lectures suivantes sur
le même descripteur de fichier compléteront la chaîne. Quand une chaîne complète a été lue,
les lectures qui suivent ne renvoient aucun octet et un nouveau descripteur de fichier doit
être ouvert pour lire une nouvelle valeur.
write(2)
Un appel à write(2) sur le fichier définit le registre à la valeur fournie dans la chaîne.
La chaîne est analysée du début jusqu'au premier caractère non numérique ou jusqu'à la fin
du tampon. Les écritures suivantes sur le même descripteur de fichier remplaceront les
précédentes écritures.
/mbox_info
/ibox_info
/wbox_info
/dma_into
/proxydma_info
Read-only files that contain the saved state of the SPU mailboxes and DMA queues. This allows the
SPU status to be inspected, mainly for debugging. The mbox_info and ibox_info files each contain
the four-byte mailbox message that has been written by the SPU. If no message has been written to
these mailboxes, then contents of these files is undefined. The mbox_stat, ibox_stat, and
wbox_stat files contain the available message count.
Le fichier wbox_info contient un tableau de messages de 4 octets qui ont été envoyés à le SPU. Sur
les machines CBEA actuelles, le tableau a une longueur de 4 éléments, ainsi, on peut lire jusqu'à
4 * 4 = 16 octets. Si une entrée de file de boîte à lettres est vide, les octets lus dans
l'emplacement correspondant sont indéterminés.
Le fichier dma_info contient le contenu de la file DMA du MFC du SPU, représenté par la structure
suivante :
struct spu_dma_info {
uint64_t dma_info_type;
uint64_t dma_info_mask;
uint64_t dma_info_status;
uint64_t dma_info_stall_and_notify;
uint64_t dma_info_atomic_command_status;
struct mfc_cq_sr dma_info_command_data[16];
};
Le dernier membre de cette structure de données est la file DMA réelle contenant 16 entrées. La
structure mfc_cq_sr est définie ainsi :
struct mfc_cq_sr {
uint64_t mfc_cq_data0_RW;
uint64_t mfc_cq_data1_RW;
uint64_t mfc_cq_data2_RW;
uint64_t mfc_cq_data3_RW;
};
Le fichier proxydma_info contient des informations similaires mais décrit la file DMA proxy
(c'est-à-dire, les DMA initiés par des entités extérieures au SPU). Le fichier a le format
suivant :
struct spu_proxydma_info {
uint64_t proxydma_info_type;
uint64_t proxydma_info_mask;
uint64_t proxydma_info_status;
struct mfc_cq_sr proxydma_info_command_data[8];
};
L'accès à ces fichiers nécessite que le contexte SPU ne soit pas ordonnancé ; une utilisation
fréquente serait inefficace. Ces fichiers ne doivent pas être utilisés dans l'exécution normale
d'un programme.
Ces fichiers n'existent pas dans les contextes créés avec l'attribut SPU_CREATE_NOSCHED.
/cntl Ce fichier fournit un accès aux registres de contrôle d'exécution et d'état du SPU sous forme
d'une chaîne ASCII. Les opérations suivantes sont prises en charge :
read(2)
La lecture du fichier cntl renverra une chaîne ASCCI contenant la valeur hexadécimale du
registre d'état du SPU.
write(2)
L'écriture dans le fichier cntl définira le registre de contrôle d'exécution du contexte du
SPU.
/mfc Fournit un accès au contrôleur de flux mémoire (MFC) du SPU. Une lecture de ce fichier renvoie le
contenu du registre d'état de balise MFC du SPU et une écriture dans le fichier initie un DMA du
MFC. Les opérations suivantes sont prises en charge :
write(2)
L'écriture dans ce fichier nécessite d'être dans le format d'une commande DMA du MFC défini
ainsi :
struct mfc_dma_command {
int32_t pad; /* réservé */
uint32_t lsa; /* adresse de stockage local */
uint64_t ea; /* adresse effective */
uint16_t size; /* taille de transfert */
uint16_t tag; /* attribut de commande */
uint16_t class; /* identifiant de la classe */
uint16_t cmd; /* opcode de la commande */
};
Les écritures doivent avoir une taille d'exactement sizeof(struct mfc_dma_command) octets.
La commande sera envoyée à la file proxy MFC du SPU et l’attribut enregistré dans le noyau
(voir ci-dessous).
read(2)
Lire le contenu du registre d'état de l’attribut. Si le fichier est ouvert en mode bloquant
(c'est-à-dire, sans O_NONBLOCK), la lecture bloquera jusqu'à ce qu'une balise DMA (comme
effectué par une écriture précédente) soit achevée. En mode non bloquant, le registre
d'état de l’attribut MFC sera renvoyé sans attente.
poll(2)
Appeler poll(2) sur le fichier mfc bloquera jusqu'à ce qu'un nouveau DMA puisse être
démarré (en vérifiant POLLOUT) ou jusqu'à ce qu'un DMA démarré précédemment (en vérifiant
POLLIN) se soit achevé.
/mss Fournit un accès à la fonctionnalité de synchronisation multisource (MSS) MFC. En
effectuant un mmap(2) sur ce fichier, les processus peuvent accéder à la zone MSS du SPU.
Les opérations suivantes sont gérées :
mmap(2)
La projection de mss dans l'espace d'adressage du processus donne accès à la zone MSS du
SPU depuis l'espace d'adressage du processus. Seules les projections MAP_SHARED sont
autorisées.
/psmap Fournit un accès à l'ensemble de la projection d'état de problèmes du SPU. Les applications
peuvent utiliser cette zone pour interfacer le SPU plutôt que d'écrire dans les fichiers
individuels des registres sur le système de fichiers spufs.
Les opérations suivantes sont gérées :
mmap(2)
La projection de psmap donne un accès direct à un processus vers la zone d'état des
problèmes du SPU. Seules les projections MAP_SHARED sont autorisées.
/phys-id
Fichier en lecture seule contenant le nombre de SPU physiques sur lesquelles s'exécutent le
contexte SPU. Lorsque le contexte n'est pas en cours d'exécution, ce fichier contient la chaîne
« -1 ».
Le nombre de SPU physiques est fourni sous forme d'une chaîne ASCII hexadécimale.
/object-id
Permet aux applications de stocker (ou récupérer) un idendifiant 64 bits dans le contexte. Cet
identifiant est utilisé plus tard par les outils de profilage pour identifier de manière unique le
contexte.
write(2)
En écrivant une valeur hexadécimale ASCII dans ce fichier, les applications peuvent définir
l'identifiant d'objet du contexte SPU. Toute valeur précédente de l'identifiant d'objet est
écrasée.
read(2)
La lecture de ce fichier fournit une chaîne hexadécimale ASCII représentant l'identifiant
d'objet de ce contexte SPU.
EXEMPLES
To automatically mount(8) the SPU filesystem when booting, at the location /spu chosen by the user, put
this line into the fstab(5) configuration file:
none /spu spufs gid=spu 0 0
VOIR AUSSI
close(2), spu_create(2), spu_run(2), capabilities(7)
The Cell Broadband Engine Architecture (CBEA) specification
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry Vignaud
<tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe Guérard
<fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-luc.coulon@wanadoo.fr>, Julien Cristau
<jcristau@debian.org>, Thomas Huriaux <thomas.huriaux@gmail.com>, Nicolas François
<nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>, Simon Paillard
<simon.paillard@resel.enst-bretagne.fr>, Denis Barbier <barbier@debian.org> et David Prévot
<david@tilapin.org>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General Public License
version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à
debian-l10n-french@lists.debian.org.
Pages du manuel de Linux 6.9.1 2 mai 2024 spufs(7)