Les dépêches noyau LinuxFr.org sont de retour. S'il sera compliqué de rattraper le retard sur les noyaux 5 (la dépêche pour le noyau 5.1 date de mai 2019), nous commençons par combler le retard doucement, en introduisant cette présentation d'un noyau de 2021.
C’est ainsi que le 27 juin 2021 est sorti le noyau Linux 5.13, coincé entre l’actualité sur la capitalisation boursière de Facebook qui dépasse les 1000 milliards et un variant Delta qui commence à prendre de l’ampleur sur fond de record au Nasdaq.
Linus nous annonce que malgré le calme de ces dernières semaines, globalement, la version 5.13 est une version plutôt importante. Avec plus de 16 000 commits de plus de 2 000 développeurs impliqués, elle fait partie des grosses versions. Et ce n’est pas, comme parfois, une intégration d’une nouvelle technologie, mais juste une tendance globale pour l'ensemble du noyau.
Architectures
M1
Cette version apporte les premières briques pour l’intégration du processeur maison d’Apple, le M1. C’est une prise en charge préliminaire, et qui permet de poser les bases.
ARM
Prise en charge de nouveaux matériels :
- le NanoPi R4S sur base de RK3399 ;
- les processeurs Qualcomm SC7280, utilisés dans certains ordinateurs de type Chromebook ou Windows ARM ;
- les téléphones OnePlus 5/5T (sur base Qualcomm MSM8998) ;
- le kit de développement Snapdragon 888 Mobile ;
- la tablette reMarkable (sur base NXP i.MX 7).
Intel
Un nouveau pilote de gestion de la température (Intel Cooling Driver) pour les processeurs Intel permet de définir un seuil de température différent du seuil par défaut pour réduire la fréquence du processeur.
Pilotes logiciel
Un nettoyage a été effectué au niveau des pilotes logiciels, incluant un certain nombre de périphérique WiMax, le framework Google gasket, les pilotes sysace et umem ainsi que certains vieux pilotes de port série. Notons aussi la suppression du fichier de bloc spécial /dev/kmem.
Dans les ajouts notables (ou visibles), on peut noter qu’après l’inclusion de pilotes pour les manettes Sony DualShock et Nintendo 64 dans le noyau 5.12, nous avons droit dans ce noyau à l’ajout du contrôleur Amazon Luna.
L’Apple Magic Mouse 2 reçoit aussi une amélioration de son pilote, via l’ajout du multitouch, ainsi qu’une supervision du niveau de la batterie.
Sécurité
Inclusion de Landlock, un nouveau module de sécurité, qui vient s’ajouter aux modules existants, pour mieux gérer la portée des processus. Son inclusion survient après 34 révisions et des années de développement.
Temps réel
Le noyau se voit adjoindre un développement venant de la branche RT Preemptive, via l’ajout des interruptions logicielles en espace noyau via un thread dédié, qui peut alors respecter une priorité spécifique, comme n’importe quel autre processus.
Statistiques
Statistiques des noyaux de la série v5.x
Statistiques des noyaux de la série v5.13-rcX
(Nous excluons la rc1 qui correspond à la fenêtre de merge)
Aller plus loin
- lwn.net - Part 1 (131 clics)
- lwn.net - Part 2 (66 clics)
- kernelnewbie - Kernel 5.13 (146 clics)
- cnx-software - 5 13 release : notable changes (61 clics)
# Thread de corrections
Posté par jmiven . Évalué à 4.
Merci pour la dépêche, bonne idée.
[^] # Re: Thread de corrections
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
Corrigé, merci.
# Et RISC-V?
Posté par tao popus . Évalué à 10. Dernière modification le 21 juillet 2021 à 23:41.
Dommage de ne pas se porter plus vers l'avenir qui commence à bien s'encrer dans le présent avec l'architecture open source RISC-V. Son support par le noyau Linux continue à se compléter.
* Support for generic clockevent broadcasts.
* Support for the buildtar build target.
* Some build system cleanups to pass more LLVM-friendly arguments.
* Support for kprobes.
Au fur et à mesure que les distributions y sont portées. Debian (Bulleseye), Ubuntu, et Fedora tourne à présent sur cette architecture, on commence à avoir des cartes autres que microcontrôleur abordables (enfin, à moins de 800€), c'est limité, plutôt orienté dev, mais ça évolue très vite. Un porteur de Haiku sur RISC-V à [utilisé le pilote radeon_hd pour faire tourner sur du Risc-V, il a visiblement principalement eu une contrainte d'alignement sur 16 bits. Ces pilotes sont aussi présent dans Debian pour RISC-V. C'est vraiment un des grands plus des sources ouvertes la portabilité. Quelqu'un fignole également la partie noyau Linux du pilote Radeon.
J'ai fait tourner du Debian sur du qemu depuis 2 mois, ça tourne plutôt bien, 95% des paquets sont portés (je pense que ce qui reste c'est ce qui test en dur une version de x86, à vérifier). J'ai quelques microcontrôleurs également pour m'amuser (on en trouve des très complets sur des cartes à partir de 3€ avec FPU, crypto, wifi, audio etc.., j'ai fait quelques essais en assembleur, c'est intéressant la conception, c'est du RISC2. Pour réduire encore le nombre d'instructions par rapport aux autres RISC, il n'y a par exemple plus que les comparateurs < et <=, plus de comparateurs > et >=, ça paraît étrange mais ça permet de réduire pas mal les transistor tout en gardant les mêmes fonctionnalités (il suffit d'inverser les registres dans le test). Les spécifications de l'assembleur comporte des macros pour faciliter l'écriture comme sur des processeurs moins optimisés. Quelqu'un s'est amusé à compiler un noyau 5.0 sur architecture RISC-V et le faire tourner sur un émulateur sur un microcontrôleur embarqué ESP32 (ISA Xtensa alors qu'il y a des ESP32-C qui sont en RISC-V). Il y a plein d'expérimentations folles en RISC-V via différents émulateurs :). Cet émulateur n'a pas l'air libre par contre :(.
Pour ceux qui s'intéresse un peu au spatial, l'ESA utilisait la famille de processeur LEON basé sur SPARC-8, pour ses satellites, les nouvelles générations baptisées NOEL-V (anagramme), sont basées sur du RISC-V, ce qui permet de réduire encore la conso. L'extension vectorielle (comme à l'époque du Cray) est utilisée pour de l'AI (traitement de photos avant l'envoie sur terre par exemple). Ça utilise le bus AMBA 2.0 d'ARM pour les SoC, dont les specs, je ne le savais pas est sous licence libre également. Les processeurs spatiaux doivent répondre aux contraintes de basse températures, et de rayons ionisants qui fausseraient les calculs sur un processeurs standard. C'est le second projet européen dont j'ai connaissance (avec le processeur européen pour supercalculateur+automobile), qui utilise du RISC-V. L'académie chinoise des sciences à aussi sorti un processeur RISC-V haut de gamme complet sous licence libre (Mulan v2), dont les sources sont en Chisel appelé Xiangshan. Ils ont sorti une implémentation ASIC avec une puissance de calcul/GHz SPEC2006 qui est comparable aux haut de gamme ARM ce mois-ci, ils espèrent atteindre le même rapport calcul/GHz qu'un i9 cet automne et c'est prévu pour faire tourner du Debian de base :).
[^] # Re: Et RISC-V?
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Bon commentaire !
Juste une remarque : "L'extension vectorielle (comme à l'époque du Cray)", non, c'est du simple SIMD comme le SSE à 128 bits (intel va jusqu'à 512 mais cela consomme trop et cela fait baisser la fréquence du chip). Le cray avait des vecteurs de 2048 double, c'est une autre taille.
"La première sécurité est la liberté"
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . Évalué à 8.
Oui et non. On parle bien d'une extension vectorielle, dans le sens ou la taille des registres n'est pas définie par l'ISA, mais par l'implémentation. Le NOEL-V a bien des registres vectoriels de 128 bits, mais un code binaire identique est capable d'exploiter des vecteurs de taille différente sur un autre CPU.
[^] # Re: Et RISC-V?
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
C'est impossible. Il est très difficile d'avoir un binaire qui s’exécute correctement avec des tailles de vecteur variables selon le cpu.
"La première sécurité est la liberté"
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . Évalué à 10.
Difficile ou impossible, il faudrait savoir. C'est très bien expliqué comment l'extension V de RISC-V implémente ça dans le livre "The RISC-V Reader: An Open Architecture Atlas" de David Patterson et Andrew Waterman.
Un cherchant un peu sur le net, j'ai également trouvé ce site qui explique pas trop mal le principe: https://gms.tf/riscv-vector.html
A noter que ARMv8 propose l'extension SVE qui fonctionne sur un principe similaire, mais avec moins de flexibilité.
[^] # Re: Et RISC-V?
Posté par Nicolas Boulay (site web personnel) . Évalué à 4.
Je serais curieux de voir ce que cela donne dans la vie réelle. J'aurais tendance à penser que ce genre d'ISA serait lente (latence entre instructions pour décoder l'info de taille à chaque fois, voir une batterie de switch pour gérer la taille dynamique).
J'aurais préféré une ISA "matricielle", c'est à dire un vecteur qui gère aussi les matrices 2*2 sur un vecteur de 4 éléments. Cela simplifie plusieurs type de calcul. De mémoire, les cpu tensorflow fonctionnent ainsi.
"La première sécurité est la liberté"
[^] # Re: Et RISC-V?
Posté par jyes . Évalué à 5.
Ça dépend de ce que tu vis dans ta vie réelle. Pour le calcul scientifique cette approche vectorielle est susceptible d’améliorer énormément les performances par rapport à tous les traitements spécifiques des fins de boucles nécessaires avec les registres de taille fixe (et toutes les heuristiques pour tenter de deviner quand le temps perdu dans ces traitements risque de contrebalancer le gain potentiel du traitement vectoriel, qui change évidemment chaque fois qu’on vise une machine un tout petit peu différente). De plus, ça veut dire que presque tous les traitements peuvent profiter des opérations vectorielles, pas seulement ceux sur un type de données, le code ainsi vectorisé s‘approche alors beaucoup d’un code réellement parallèle. Pour tout le (assez peu de) code que j’écris, je n’aurais rien à faire de matrices 2×2 (éventuellement je me servirais de 3×3 mais pas assez pour gagner quoi que ce soit si des opérations de base existaient pour elles), par contre la vectorisation change tout.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . Évalué à 7.
Je suis tout à fait d'accord, il ne faut pas tout réduire à du calcul matriciel. Par exemple grâce aux instructions vectorielles "fault-only-first load", il est notamment possible de travailler sur des chaînes de caractères sans contrainte d'alignement et sans connaître leur longueur à priori.
Ainsi une implémentation de strlen() vectorisée reste très simple:
https://github.com/gsauthof/riscv/blob/master/strlen.s
À comparer à une implémentation AVX2 pour x86:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/x86_64/multiarch/strlen-avx2.S
Sans compter que pour x86, il faut aussi la version AVX-512 pour les CPUs serveurs, et la version SSE2 pour l'entrée de gamme.
[^] # Re: Et RISC-V?
Posté par tao popus . Évalué à 2.
Complètement, il y a aussi les traitements de données type RRD, comme ceux arrivant de différents capteurs et qui doivent être traitées en série.
[^] # Re: Et RISC-V?
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Là, je ne vois pas pourquoi. En général, pour faire cela il faut du scatter/gather ou des load/store vectorisé, ce qui n'existe jamais.
Je comprends que cela simplifie le code à générer. Mais cela peut vite ajouter un étage de pipeline pour le calcul avec toutes les latences qui vont avec.
"La première sécurité est la liberté"
[^] # Re: Et RISC-V?
Posté par tao popus . Évalué à 6.
Je crois qu'il y a un problème de compréhension du fonctionnement d'une unité vectorielle comme celle-ci. Le but est bien de traiter des ensemble de donnée en série.
Voici une présentation de 2015 à ce sujet qui explique les avantages du processeur vectoriel traditionnel par rapport au packed-SIMD et quelques améliorations apportées dans le cas de l'extension vectorielle de RISC-V :
https://riscv.org/wp-content/uploads/2015/06/riscv-vector-workshop-june2015.pdf
[^] # Re: Et RISC-V?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Le doc est intéressant, je ne connaissais pas le "vectorielle classique". Mais il n'y a pas plus de scatter/gather de données en RAM, qui permettrait de vectoriser plus ou moins n'importe quel code (vecteur de pointeur pour faire un load/store vectoriel).
"La première sécurité est la liberté"
[^] # Re: Et RISC-V?
Posté par tao popus . Évalué à 5.
De ce que je comprend par « scatter/gather » (en français disperser/rassembler), avoir des des données éparpillées au hasard et récupérer tout ça pour le traitement, c'est une bonne idée si on veut sortir des caches et multiplier les temps de calculs. Organiser les données en mémoire fait parti du travail d'optimisation d'une application.
Les mémoires des processeurs graphiques par exemple contiennent ce que l'on appelle en OpenGL des VBO (Vertex Buffer Object=Objet tampon de vecteurs), qui sont des tables de vecteurs. Le processeur graphique peut appliquer linéairement un changement sur l'ensemble des points d'un objet en une seule boucle. C'est le type de tampon qu'on initialise lors de la création de l'objet qui reste dans la carte graphique, et dont on charge le processeur graphique d'effectuer des traitements sur ses données.
Dans les premières version d'OpenGL on poussait tous les points dans la pile OpenGL à chaque image à générer (transfert de la ram principale vers la ram graphique) ce qui était vraiment contre-productif. De plus les données n'ont pas forcément à être modifiées systématiquement. Par contre à chaque rendu, le GPU va appliquer les transformations (rotation/échelle/déformation+perspective) sur l'ensemble des vecteurs de l'objet, qu'il appliquera via une boucle. Il en va de même dans quasiment tous les domaines je pense. Comme évoqué précédemment, chaîne de caractères, informations venant linéairement de capteurs, ou bien encore échantillon sonore, etc.
Le principe d'un processeur vectoriel est de définir, comme expliqué dans le document :
* Le type de donnée
* Une suite d'instruction à effectuer sur ce type de données dans une boucle
* la longueur de la boucle.
Et de laisser le processeur vectoriel effectuer cette boucle sur l'ensemble des données.
À la premier lecture les blocs de mémoire contenant les données seront mis en cache données et le processeur pourra boucler sur les données avec ces instructions contenues dans le cache instruction. On économise toutes les instructions d'incrémentation/chargement qui peuvent être fait en parallèle aux instructions de traitement avec un cycle d'avance.
Si on utilise ce type de processeur sur des données ponctuelles éparpillées la différence de cycle de traitement ne sera en revanche pas énorme, ça se joue à 2 ou 3 instructions comme montré dans les exemples, ce qui est négligeable par rapport au temps de lecture aléatoire en RAM ou dans des caches de niveaux intermédiaires. Ces cycles sont par contre à multiplier par le nombre de boucles dans le cas de données organisées pour un traitement linéaire.
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . Évalué à 5.
Dans la vie réelle, il y a l'exemple de Cray qui avait un principe de fonctionnement similaire au niveau des vecteur de longueur variable et qui fonctionnait très bien.
Côté ARMv8 SVE, qui est tout de même un peu différent je l'admet, il y a quand même le supercalculateur Fugaku qui arrive premier au Top 500 sans utiliser de GPU.
[^] # Re: Et RISC-V?
Posté par StyMaar . Évalué à 4.
Ça me fait penser à des problèmes un peu similaire (bon, seulement un peu) avec AVX512, pas tant pour gérer un taille dynamique, mais pour gérer la consommation électrique des CPU
En gros, il y a 3 modes de puissance (Regular, AVX2 heavy et AVX512 heavy) avec chacun une réduction de la fréquence d'horloge du CPU, et le fait d'utiliser des instructions AVX2 ou AVX512 bascule le CPU vers le mode de puissance adapté pour plusieurs millisecondes.
[^] # Re: Et RISC-V?
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Ils doivent avoir des multiplieurs sous des power domaines différents, donc, pour tous les utiliser il faut leur laisser le temps de s'allumer, mais à moins d'avoir un gros TDP et une grosse ventilation, cela peut impliquer de baisser la fréquence (ce qui est absurde quelques part, car vous vous êtes fait chier à ajouter plein de bascules pour faire un long pipline pour aller plus vite, tout ça pour baisser la fréquence ! (d'ou l'archi big.little de arm, d'ailleurs)).
"La première sécurité est la liberté"
[^] # Re: Et RISC-V?
Posté par reno . Évalué à 2.
Moins de flexibilité SVE/SVE2?
Peut être mais lors d'un article qui comparait les 2 ( https://erik-engheim.medium.com/arm-vs-risc-v-vector-extensions-992f201f402f ) le code ARM était plus court, ce que j'interprète comme "potentiellement plus efficace"..
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . Évalué à 4.
SVE utilise la prédication pour faire des calculs sur une partie des élements d'un vecteur, notamment utile pour la dernière itération lorsque le nombre d'éléments d'un calcul n'est pas un multiple du nombre d'éléments d'un vecteur. Cela a pour conséquence que la taille d'un registre vectoriel a une limite finie, choisie à 2048 bits pour SVE.
RISC-V n'a pas cette limite, et on peut avoir des registres vectoriels beaucoup plus grands. Cela est avantageux notamment car RISC-V permet de ré-organiser l'espace mémoire de l'unité vectorielle et de réattribuer la mémoire des registres vectoriels inutilisés à d'autres. À noter qu'il n'y a pas forcément autant d'unité de calculs disponibles en hardware que la taille d'un vecteur, mais ces opérations se pipelinent très bien, et du coup il est possible d'utiliser un pipeline in-order tout en restant efficace.
[^] # Re: Et RISC-V?
Posté par barmic 🦦 . Évalué à 3.
C'est bien de prédiction dont tu parle ?
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et RISC-V?
Posté par Aurélien Jarno (site web personnel) . Évalué à 7.
Non, c'est bien de prédication, mais en fait c'est un anglicisme désolé. "Prédicat" existe bien en français, mais en anglais il y a aussi le mot "Predication" pour désigner la fonctionnalité. Voir https://en.wikipedia.org/wiki/Predication_(computer_architecture) . En résumé, c'est le fait de pouvoir masquer certains éléments d'un vecteur lors des opérations. C'est notamment utilisé dans SVE pour masquer les éléments de la dernière itération, même si d'autres usages sont possibles.
[^] # Re: Et RISC-V?
Posté par barmic 🦦 . Évalué à 4.
Oh je suis bien content d'avoir posé ma question du coup :)
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Et RISC-V?
Posté par reno . Évalué à 2. Dernière modification le 29 juillet 2021 à 10:24.
Merci pour ta réponse, effectivement j'avais oublié cette limitation en longueur des ARM SVE.
[^] # Re: Et RISC-V?
Posté par antistress (site web personnel) . Évalué à 6.
Top le complément à la dépêche, cimer !
# stats
Posté par moi1392 . Évalué à 5. Dernière modification le 22 juillet 2021 à 09:29.
D'abord merci pour la dépêche, j'ai rarement commenté les dépêche noyau et malheureusement jamais participé à leur rédaction (je ne m'estime pas assez compétent pour cela), mais depuis qu'elles existent, je les ai toujours assidument lues.
En voyant les stats d'ajouts/retraits de lignes pour les RC, je suis surpris de voir qu'ils sont relativement constants tout au long des RC, je voyait ça beaucoup plus dégressif.
Quelqu'un sait si c'est un cas particulier de cette version ou si c'est toujours le cas ?
PS: comme quoi faut toujours mieux aller chercher des stats plutôt que je fier à son ressenti…
[^] # Re: stats
Posté par Nicolas Boulay (site web personnel) . Évalué à 3. Dernière modification le 22 juillet 2021 à 10:29.
J'imagine que c'est le nombre de ces changements qui décide de sortir une nouvelle RC à la place de la finale.
"La première sécurité est la liberté"
# Landlock
Posté par antistress (site web personnel) . Évalué à 5.
Quelqu'un pour dire un mot dessus ? Je suis curieux !
[^] # Re: Landlock
Posté par barmic 🦦 . Évalué à 5.
De ce que je comprends que le site, c'est comme seccomp, mais uniquement pour le fs. L'idée c'est que les développeurs vont pouvoir sandboxer une partie ou une partie d'une application pour qu'elle est ou non accès en lectur/écriture/exécution à tout ou partie du système de fichier.
Il doit être un peu plus simple à utiliser que seccomp qui lui va intercepter les appels systèmes et donc pour faire la même chose il faut aller regarder comment est utilisé
open(). À noter que pour raison que j'ignore landlock ne passe plus par eBPF pour faire ça (contrairement à seccomp).https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Landlock
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 24 juillet 2021 à 01:36.
Merci
Et une techno comme Flatpak s'appuie sur quelle techno du noyau pour limiter l'accès au fs ? Ou ça n'a rien à voir ?
[^] # Re: Landlock
Posté par barmic 🦦 . Évalué à 7.
De ce que je sais, LXC, docker, flatpak,… Utilisent chroot. Il est le plus vieux, le plus simple (on m'a toujours dit que c'était pas génial en terme de sécurité). chroot permet de lancer un processus en indiquant un dossier comme étant son dossier racine. Par exemple si tu as un fichier
/a/b/cet que tu lance un processus en choisissant/a/b, pour ce nouveau processus le fichier c se trouve à la racine/c.Chroot ne demande pas de modifier les programmes pour être utilisé contrairement à seccomp, landlock.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Landlock
Posté par antistress (site web personnel) . Évalué à 2.
Merci !
C'est assez complexe mais intéressant
[^] # Re: Landlock
Posté par barmic 🦦 . Évalué à 2.
Oui, je ne fais qu'effleurer le sujet. La sécurité est très complexe et ça demande de sacrées compétences pour blinder un système. Seccomp, capsicum, les lsm de base,… S'y retrouver peut être difficile.
J'ai appris avec landlock que les lsm peuvent maintenant être empilable alors qu'avant ils étaient forcément mutuellement exclusifs.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Landlock
Posté par claudex . Évalué à 8.
Alors, LXC et docker n'utilisent pas chroot mais les namespaces (et pas uniquement sur le filesystem d'ailleurs). Cela revient au même pour ta description, mais au niveau implémentation c'est assez différent il me semble et il y a une meilleure isolation au final.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: Landlock
Posté par barmic 🦦 . Évalué à 6. Dernière modification le 24 juillet 2021 à 16:26.
Effectivement j'étais persuadé qu'il n'y avait pas de namespace pour le système de fichier alors que si et depuis longtemps (branche 2.4 du noyau). Les problèmes de sécurité de chroot n'existent pas pour le namespace mount.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Landlock
Posté par EdB . Évalué à 3.
Ca marche avec les techno container et in fine les namespaces qui sont des techno qui font en sorte que le processus est une vision changée de leur environnement
# cool
Posté par mlinux . Évalué à 5.
merci pour ces dépêches, ca permet de lire des nouvelles fraiches, en français, ce qui donne aussi un apercu de la communauté locale, donc oui on vous lit ;)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.