NOM
spufs - Le système de fichiers SPU
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.
Tous les fichiers gèrent les opération chmod(2)/fchmod(2) et
chown(2)/fchown(2), mais ne permettront pas des autorisations d’accès
qui contredisent les opérations possibles pour un fichier (par exemple,
l’accès en lecture pour un fichier wbox).
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 kilo-octets.
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’éxecution 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, 4
octets sont placés dans le tampon de données et la valeur
renvoyée est 4.
/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 4 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
Ce sont des fichiers en lecture seule qui contiennent la taille
des différentes queues des boîtes aux lettres, c’est-à-dire le
nombre de mots qui peuvent être lus dans mbox ou ibox ou peuvent
être écrits dans wbox sans bloquer. Ces fichiers ne peuvent être
lus que par blocs de 4 octets et renvoient un nombre entier avec
un codage grand boutiste (« big endian ». La seule opération
possible sur un fichier *box_stat ouvert est :
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 spécifié. 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’éxecution 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 drapeaux 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 fixe 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 4 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
spécifié.
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
spécifié. 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 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ération 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 fixe 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
Fichiers en lecture seule qui contiennent l’état sauvegardé des
boîtes à lettres SPU et des files DMA. Cela permet de pourvoir
consulter l’état du SPU, principalement à des fins de débogage.
Les fichiers mbox_info et ibox_info contiennent chacun un
message de 4 octets qui a été écrit par le SPU. Si aucun message
n’a été écrit dans ces boîtes à lettres, le contenu de ces
fichiers est indéterminé. Les fichiers mbox_stat, ibox_stat et
wbox_stat contient le nombre de messages disponibles.
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; /* drapeau 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 le drapeau
enregistré dans le noyau (voir ci-dessous).
read(2)
Lire le contenu du registre d’état du drapeau. 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 du
drapeau 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.
EXEMPLE
Entrée /etc/fstab
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
COLOPHON
Cette page fait partie de la publication 3.23 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent être trouvées à l’adresse
http://www.kernel.org/doc/man-pages/.
TRADUCTION
Cette page de manuel a été traduite et est maintenue par Julien Cristau
<julien.cristau@ens-lyon.org> et l’équipe francophone de traduction de
Debian.
Veuillez signaler toute erreur de traduction en écrivant à
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir accès à la version anglaise de ce document
en utilisant la commande « man -L C <section> <page_de_man> ».