Noyau Linux - Linux kernel

Noyau Linux
Smoking
Tux le pingouin, mascotte de Linux
Linux 3.0.0 boot.png
Démarrage du noyau Linux 3.0.0
Développeur Contributeurs de la communauté
Linus Torvalds
Écrit en C , Langage assembleur
Famille d'OS Unix-like
Première version 0,02 (5 octobre 1991 ; il y a 30 ans ) ( 1991-10-05 )
Dernière version 5.14.10  Modifiez ceci sur Wikidata/ 7 octobre 2021 ; il y a 10 jours ( 7 octobre 2021 )
Dernier aperçu 5.15-rc4  Modifiez ceci sur Wikidata/ 3 octobre 2021 ; il y a 14 jours ( 3 octobre 2021 )
Dépôt
Disponible en Anglais
Type de noyau Monolithique
Licence GPL-2.0 uniquement avec Linux-syscall-note
Site officiel www .kernel .org

Le noyau Linux est un libre et open-source , monolithique , modulaire , multi - tâches , Unix système d' exploitation noyau . Il a été conçu et créé en 1991 par Linus Torvalds pour son PC basé sur i386 , et il a rapidement été adopté comme noyau pour le système d'exploitation GNU , qui a été créé pour remplacer gratuitement UNIX . Depuis lors, il a engendré un grand nombre de distributions de systèmes d' exploitation , communément aussi appelées Linux .

Linux est déployé sur une grande variété de systèmes informatiques, tels que des appareils embarqués , des appareils mobiles (y compris son utilisation dans le système d' exploitation Android ), des ordinateurs personnels , des serveurs , des mainframes et des superordinateurs . Il peut être adapté à des architectures spécifiques et à plusieurs scénarios d'utilisation à l'aide d'une famille de commandes simples (c'est-à-dire sans avoir besoin d'éditer manuellement son code source avant la compilation) ; les utilisateurs privilégiés peuvent également affiner les paramètres du noyau lors de l'exécution. La plupart du code du noyau Linux est écrit en utilisant les extensions GNU de GCC au langage de programmation C standard et avec l'utilisation d'instructions spécifiques à l'architecture ( ISA ). Cela produit un exécutable hautement optimisé ( vmlinux ) en ce qui concerne l'utilisation de l'espace mémoire et les temps d'exécution des tâches.

Les discussions quotidiennes sur le développement ont lieu sur la liste de diffusion du noyau Linux (LKML). Les modifications sont suivies à l'aide du système de contrôle de version git , qui a été créé par Torvalds pour remplacer sur mesure BitKeeper . Linux dans son ensemble est publié sous la licence publique générale GNU version 2 uniquement (GPL-2.0 uniquement) avec une exception explicite d'appel système (Linux-syscall-note), mais il contient également plusieurs fichiers sous d'autres licences compatibles.

Histoire

Linus Torvalds à la LinuxCon Europe 2014 à Düsseldorf

En avril 1991, Linus Torvalds , alors étudiant en informatique de 21 ans à l' université d'Helsinki , en Finlande , a commencé à travailler sur quelques idées simples pour un système d'exploitation. Il a commencé avec un sélecteur de tâches en langage assembleur Intel 80386 et un pilote de terminal . Le 25 août 1991, Torvalds a posté ce qui suit sur comp.os.minix , un groupe de discussion sur Usenet :

Je fais un système d'exploitation (gratuit) (juste un passe-temps, ne sera pas grand et professionnel comme gnu) pour 386 (486) clones AT . Cela brasse depuis avril et commence à se préparer. J'aimerais avoir des commentaires sur des choses que les gens aiment/n'aiment pas dans minix, car mon système d'exploitation lui ressemble un peu (même disposition physique du système de fichiers (pour des raisons pratiques) entre autres). J'ai actuellement porté bash (1.08) et gcc (1.40), et les choses semblent fonctionner. Cela implique que j'obtiendrai quelque chose de pratique d'ici quelques mois [...] Oui - c'est libre de tout code minix, et il a un fs multi-thread. Il n'est PAS protable [ sic ] (utilise 386 commutations de tâches, etc.), et il ne prendra probablement jamais en charge autre chose que les disques durs AT, car c'est tout ce que j'ai :-(.

Le 17 septembre 1991, Torvalds a préparé la version 0.01 de Linux et mis sur le "ftp.funet.fi" - serveur FTP de l'Université finlandaise et du réseau de recherche ( FUNET ). Il n'était même pas exécutable car son code avait encore besoin de Minix pour la compilation et la lecture.

Le 5 octobre 1991, Torvalds a annoncé la première version "officielle" de Linux, la version 0.02. À ce stade, Linux était capable d'exécuter Bash, GCC et d'autres utilitaires GNU :

[Comme] je l'ai mentionné il y a un mois, je travaille sur une version gratuite d'un sosie de Minix pour les ordinateurs AT-386. Il a finalement atteint le stade où il est même utilisable (bien que cela ne dépende peut-être pas de ce que vous voulez), et je suis prêt à publier les sources pour une distribution plus large. Il ne s'agit que de la version 0.02... mais j'ai exécuté avec succès bash, gcc, gnu-make, gnu-sed, compress, etc.

Après cela, de nombreuses personnes ont contribué au code du projet, y compris certains développeurs de la communauté MINIX . À l'époque, le projet GNU avait créé de nombreux composants requis pour un système d'exploitation libre, mais son propre noyau, GNU Hurd , était incomplet et indisponible. La Berkeley Software Distribution ne s'était pas encore libérée des contraintes juridiques . Malgré les fonctionnalités limitées des premières versions, Linux a rapidement gagné des développeurs et des utilisateurs.

Torvalds a attribué la version 0 au noyau pour indiquer qu'il était principalement destiné aux tests et non destiné à une utilisation productive. La version 0.11, publiée en décembre 1991, était le premier Linux auto-hébergé , car il pouvait être compilé par un ordinateur exécutant le même noyau.

Lorsque Torvalds a publié la version 0.12 en février 1992, il a adopté la licence publique générale GNU version 2 (GPLv2) sur sa précédente licence auto-rédigée, qui n'avait pas autorisé la redistribution commerciale. Contrairement à Unix , tous les fichiers sources de Linux sont disponibles gratuitement, y compris les pilotes de périphériques . Le succès initial de Linux a été motivé par des programmeurs et des testeurs du monde entier. Avec le support des API POSIX , via la libC qui, si nécessaire, agit comme un point d'entrée vers l'espace d'adressage du noyau, Linux pouvait exécuter des logiciels et des applications qui avaient été développés pour Unix.

Le noyau Linux prend en charge diverses architectures matérielles, fournissant une plate-forme commune pour les logiciels, y compris les logiciels propriétaires .

Le 19 janvier 1992, le premier message du nouveau groupe de discussion alt.os.linux a été soumis. Le 31 mars 1992, le groupe de discussion a été renommé comp.os.linux . Le fait que Linux soit un noyau monolithique plutôt qu'un micronoyau était le sujet d'un débat entre Andrew S. Tanenbaum , le créateur de MINIX, et Torvalds. Le débat Tanenbaum-Torvalds a commencé en 1992 sur le groupe Usenet comp.os.minix en tant que discussion générale sur les architectures du noyau.

La version 0.95 de Linux a été la première à être capable d'exécuter le système X Window . En mars 1994, Linux 1.0.0 est sorti avec 176 250 lignes de code. Il s'agissait de la première version adaptée à une utilisation dans des environnements de production .

Il a lancé un système de gestion de versions pour le noyau avec trois ou quatre chiffres séparés par des points, le premier représentant la version majeure , le second la version mineure et le troisième la révision. À cette époque, les versions mineures impaires étaient destinées au développement et aux tests, tandis que les versions mineures paires étaient destinées à la production. Le quatrième chiffre facultatif indiquait un ensemble de correctifs pour une révision. Les versions de développement étaient indiquées par le suffixe -rc ("release candidate").

La numérotation de la version actuelle est légèrement différente de celle ci-dessus. La numérotation paire/impaire a été abandonnée et une version majeure spécifique est désormais indiquée par les deux premiers nombres, pris dans leur ensemble. Alors que le calendrier est ouvert pour le développement de la prochaine version majeure , le suffixe -rcN est utilisé pour identifier la nième version candidate pour la prochaine version. Par exemple, la sortie de la version 4.16 a été précédée de sept 4.16-rcN (de -rc1 à -rc7). Une fois qu'une version stable est créée, sa maintenance est transférée à « l'équipe stable ». Les mises à jour occasionnelles des versions stables sont identifiées par un schéma de trois numéros (par exemple, 4.13.1, 4.13.2, ..., 4.13.16) .

Après la version 1.3 du noyau, Torvalds a décidé que Linux avait suffisamment évolué pour justifier un nouveau numéro majeur , il a donc publié la version 2.0.0 en juin 1996. La série comprenait 41 versions. La principale caractéristique de 2.0 était la prise en charge du multitraitement symétrique (SMP) et la prise en charge d'un plus grand nombre de types de processeurs.

À partir de la version 2.0, Linux est configurable pour sélectionner des cibles matérielles spécifiques et pour activer des fonctionnalités et des optimisations spécifiques à l'architecture. La famille de commandes make *config de kbuild est utilisée pour activer et configurer des milliers d'options pour créer des exécutables de noyau ad hoc ( vmlinux ) et des modules chargeables.

La version 2.2, publiée le 20 janvier 1999, a amélioré la granularité du verrouillage et la gestion SMP, ajouté la prise en charge de m68k , PowerPC , Sparc64 , Alpha et d'autres plates-formes 64 bits. En outre, il a ajouté de nouveaux systèmes de fichiers , y compris Microsoft de NTFS capacité en lecture seule. En 1999, IBM a publié ses correctifs pour le code Linux 2.2.13 pour le support de l' architecture S/390 .

La version 2.4.0, publiée le 4 janvier 2001, contenait la prise en charge des cartes ISA Plug and Play , USB et PC Cards . Linux 2.4 a ajouté le support pour le Pentium 4 et Itanium (ce dernier a introduit l' ISA ia64 qui a été développé conjointement par Intel et Hewlett-Packard pour remplacer l'ancien PA-RISC ), et pour le nouveau processeur MIPS 64 bits . Développement pour 2.4. x a un peu changé en ce sens que davantage de fonctionnalités ont été rendues disponibles tout au long de la série, notamment la prise en charge de Bluetooth , Logical Volume Manager (LVM) version 1, la prise en charge de RAID , InterMezzo et les systèmes de fichiers ext3 .

La version 2.6.0 est sortie le 17 décembre 2003. Le développement de la 2.6. x a encore évolué pour inclure de nouvelles fonctionnalités tout au long de la série. Parmi les modifications apportées à la série 2.6 figurent : l'intégration de µClinux dans les sources du noyau principal, la prise en charge de PAE , la prise en charge de plusieurs nouvelles lignes de processeurs , l'intégration d'Advanced Linux Sound Architecture (ALSA) dans les sources du noyau principal, la prise en charge de jusqu'à 2 32 utilisateurs (au lieu de 2 16 ), prise en charge d'un maximum de 2 29 identifiants de processus (64 bits uniquement, arches 32 bits toujours limitées à 2 15 ), a considérablement augmenté le nombre de types d'appareils et le nombre d'appareils de chaque type, prise en charge 64 bits améliorée , prise en charge des systèmes de fichiers prenant en charge des tailles de fichiers allant jusqu'à 16 téraoctets , préemption dans le noyau , prise en charge de la bibliothèque de threads POSIX native (NPTL), intégration Linux en mode utilisateur dans les sources principales du noyau, Intégration de SELinux dans les sources principales du noyau, prise en charge d' InfiniBand et bien plus encore.

L'ajout d'une large sélection de systèmes de fichiers à partir de la version 2.6. versions x : désormais, le noyau prend en charge un grand nombre de systèmes de fichiers, dont certains ont été conçus pour Linux, comme ext3 , ext4 , FUSE , Btrfs , et d'autres qui sont natifs d'autres systèmes d'exploitation comme JFS , XFS , Minix, Xenix , Irix , Solaris , Système V , Windows et MS-DOS .

En 2005, l' équipe stable a été formée en réponse au manque d'arborescence du noyau où les gens pourraient travailler sur les corrections de bogues , et elle continuerait à mettre à jour les versions stables . En février 2008, l' arborescence linux-next a été créée pour servir d'endroit où les correctifs destinés à être fusionnés au cours du prochain cycle de développement ont été rassemblés. Plusieurs mainteneurs de sous-systèmes ont également adopté le suffixe -next pour les arbres contenant du code qu'ils ont l'intention de soumettre pour inclusion dans le prochain cycle de publication. Depuis janvier 2014, la version en développement de Linux est conservée dans une branche instable nommée linux-next .

Linux était maintenu sans l'aide d'un système de gestion de code source automatisé jusqu'à ce qu'en 2002, le développement passe à BitKeeper . Il était disponible gratuitement pour les développeurs Linux mais ce n'était pas un logiciel libre . En 2005, à cause des efforts de rétro-ingénierie , la société qui possédait le logiciel a révoqué le soutien de la communauté Linux. En réponse, Torvalds et d'autres ont écrit Git . Le nouveau système a été écrit en quelques semaines, et en deux mois, le premier noyau officiel fabriqué en l'utilisant a été publié.

Des détails sur l'historique de la série de noyaux 2.6 peuvent être trouvés dans les fichiers ChangeLog sur la zone de publication du code source de la série de noyaux 2.6 de kernel.org .

Le 20e anniversaire de Linux a été célébré par Torvalds en juillet 2011 avec la sortie de la version du noyau 3.0.0. Comme 2.6 est le numéro de version depuis 8 ans, une nouvelle personnalité uname26 qui signale 3.x comme 2.6.40+x a dû être ajoutée au noyau pour que les anciens programmes fonctionnent.

La version 3.0 est sortie le 22 juillet 2011. Le 30 mai 2011, Torvalds a annoncé que le grand changement était "RIEN. Absolument rien". et a demandé, "... assurons-nous que nous faisons vraiment la prochaine version non seulement un tout nouveau numéro brillant, mais aussi un bon noyau." Après les 6 à 7 semaines attendues du processus de développement, il sortirait à l'approche du 20e anniversaire de Linux.

Le 11 décembre 2012, Torvalds a décidé de réduire la complexité du noyau en supprimant la prise en charge des processeurs i386 , faisant de la série de noyaux 3.7 la dernière à prendre en charge le processeur d'origine. Prise en charge unifiée de la même série pour le processeur ARM .

La version 3.11, publiée le 2 septembre 2013, ajoute de nombreuses nouvelles fonctionnalités telles que le nouvel indicateur O_TMPFILE pour open(2)réduire les vulnérabilités des fichiers temporaires, la gestion de l'alimentation dynamique expérimentale AMD Radeon , l'interrogation du réseau à faible latence et zswap (cache d'échange compressé).

Le changement de numérotation de 2.6.39 à 3.0, et de 3.19 à 4.0, n'impliquait aucune différenciation technique significative. Le numéro de version majeur a été augmenté pour éviter les grands nombres mineurs. Les noyaux stables 3.xy ont été publiés jusqu'à 3.19 en février 2015.

En avril 2015, Torvalds a publié la version 4.0 du noyau. En février 2015, Linux avait reçu des contributions de près de 12 000 programmeurs de plus de 1 200 entreprises, dont certains des plus grands fournisseurs de logiciels et de matériel au monde. La version 4.1 de Linux, publiée en juin 2015, contient plus de 19,5 millions de lignes de code fournies par près de 14 000 programmeurs.

Au total, 1 991 développeurs, dont 334 premiers collaborateurs, ont ajouté plus de 553 000 lignes de code à la version 5.8, battant ainsi le record précédemment détenu par la version 4.9.

Selon l'enquête annuelle des développeurs de Stack Overflow de 2019, plus de 53% de tous les répondants ont développé des logiciels pour Linux OS et environ 27% pour Android , bien que seulement 25% environ développent avec des systèmes d'exploitation basés sur Linux.

La plupart des sites Web fonctionnent sur des systèmes d'exploitation basés sur Linux et les 500 superordinateurs les plus puissants du monde utilisent une sorte de système d'exploitation basé sur Linux.

Les distributions Linux regroupent le noyau avec des logiciels système (par exemple, la bibliothèque GNU C , systemd et d'autres utilitaires et démons Unix ) et une large sélection de logiciels d'application , mais leur part d'utilisation sur les ordinateurs de bureau est faible par rapport aux autres systèmes d'exploitation.

Android , qui représente la majorité de la base installée de tous les systèmes d'exploitation pour appareils mobiles, est responsable de l'utilisation croissante du noyau Linux, ainsi que de sa large utilisation dans une grande variété d' appareils embarqués .

Architecture et fonctionnalités

Carte du noyau Linux

Linux est un noyau monolithique avec une conception modulaire (par exemple, il peut insérer et supprimer des modules de noyau chargeables au moment de l'exécution), prenant en charge la plupart des fonctionnalités une fois uniquement disponibles dans les noyaux à source fermée des systèmes d'exploitation non libres. Le reste de l'article utilise la convention des systèmes d'exploitation UNIX et de type Unix sur les pages de manuel officielles . Les numéros qui suivent le nom des commandes, interfaces et autres fonctionnalités ont pour but de spécifier la section (c'est-à-dire le type de composant ou de fonctionnalité du système d'exploitation) à laquelle elles appartiennent (par exemple, execve(2) fait référence à un appel système , tandis que exec(3) fait référence à un wrapper de bibliothèque en espace utilisateur). La liste suivante et les sections suivantes décrivent un aperçu non exhaustif de la conception architecturale Linux et de certaines de ses fonctionnalités remarquables.

  • Le calcul simultané et (avec la disponibilité de suffisamment de cœurs de processeur pour les tâches prêtes à être exécutées) même une véritable exécution parallèle de plusieurs processus à la fois (chacun d'entre eux ayant un ou plusieurs threads d'exécution ) sur les architectures SMP et NUMA .
  • Sélection et configuration de centaines de fonctionnalités et de pilotes du noyau (à l'aide de l'une des commandes de la famille make *config , avant de lancer la compilation), modification des paramètres du noyau avant le démarrage (généralement en insérant des instructions dans les lignes du menu GRUB2 ) et réglage fin du comportement du noyau à l'exécution (en utilisant l' interface sysctl(8) vers /proc/sys/ ).
  • Configuration (à nouveau à l'aide des commandes make *config ) et modifications à l'exécution des politiques (via nice(2) , setpriority(2) et la famille d' appels système sched_*(2) ) des planificateurs de tâches qui permettent le multitâche préemptif ( à la fois en mode utilisateur et, depuis la série 2.6, en mode noyau ); le Completely Fair Scheduler (CFS) est le programmateur par défaut de Linux depuis 2007 et il utilise un arbre rouge-noir qui peut rechercher, insérer et supprimer des informations de processus ( struct de tâche ) avec une complexité temporelle O (log n) , où n est le nombre de tâches exécutables.
  • Gestion avancée de la mémoire avec mémoire virtuelle paginée .
  • Communication inter-processus et mécanisme de synchronisation .
  • Un système de fichiers virtuel au-dessus de plusieurs systèmes de fichiers concrets ( ext4 , Btrfs , XFS , JFS , FAT32 , et bien d'autres).
  • Planificateurs d'E/S configurables, appel système ioctl(2) qui manipule les paramètres de périphérique sous-jacents de fichiers spéciaux (il s'agit d'un appel système non standard, car les arguments, les retours et la sémantique dépendent du pilote de périphérique en question), prise en charge de POSIX asynchrone I /O (cependant, parce qu'ils s'adaptent mal aux applications multithread, une famille d'appels système d'E/S spécifiques à Linux ( io_*(2) ) a dû être créée pour la gestion des contextes d'E/S asynchrones adaptés au traitement simultané).
  • Virtualisation au niveau du système d'exploitation (avec Linux-VServer ), paravirtualisation et virtualisation assistée par matériel (avec KVM ou Xen , et en utilisant QEMU pour l'émulation matérielle) ; Sur l' hyperviseur Xen , le noyau Linux prend en charge la création de distributions Linux (telles que openSuSE Leap et bien d'autres) qui fonctionnent comme Dom0 , qui sont des serveurs hôtes de machines virtuelles qui fournissent l'environnement de gestion pour les machines virtuelles de l'utilisateur ( DomU ).
  • Virtualisation des E/S avec VFIO et SR-IOV . L'E/S de fonction virtuelle (VFIO) expose l'accès direct au périphérique à l'espace utilisateur dans un environnement protégé par mémoire sécurisée (IOMMU). Avec VFIO, un invité VM peut accéder directement aux périphériques matériels sur le serveur hôte VM. Cette technique améliore les performances, si on la compare à la fois à la virtualisation complète et à la paravirtualisation. Cependant, avec VFIO, les périphériques ne peuvent pas être partagés avec plusieurs invités VM. La virtualisation d'E/S à racine unique (SR-IOV) combine les gains de performances de VFIO et la possibilité de partager un périphérique avec plusieurs invités VM (mais elle nécessite un matériel spécial qui doit être capable d'apparaître à deux ou plusieurs invités VM comme des périphériques différents) .
  • Mécanismes de sécurité pour le contrôle d'accès discrétionnaire et obligatoire (SELinux, AppArmor, POSIX ACLs et autres).
  • Plusieurs types de protocoles de communication en couches (y compris la suite de protocoles Internet ).

La plupart des pilotes de périphériques et des extensions de noyau s'exécutent dans l' espace noyau ( anneau 0 dans de nombreuses architectures de processeur ), avec un accès complet au matériel. Certaines exceptions s'exécutent dans l'espace utilisateur ; des exemples notables sont les systèmes de fichiers basés sur FUSE /CUSE et des parties d'UIO. De plus, le système X Window et Wayland , le système de fenêtrage et les protocoles de serveur d'affichage que la plupart des gens utilisent avec Linux, ne s'exécutent pas dans le noyau. Différemment, l'interfaçage réel avec les GPU des cartes graphiques est un sous-système intégré au noyau appelé Direct Rendering Manager ( DRM ).

Contrairement aux noyaux monolithiques standard, les pilotes de périphériques sont facilement configurés en tant que modules et chargés ou déchargés pendant que le système est en cours d'exécution et peuvent également être préemptés dans certaines conditions afin de gérer correctement les interruptions matérielles et de mieux prendre en charge le multitraitement symétrique . Par choix, Linux n'a pas d' interface binaire d'application de pilote de périphérique stable .

Linux utilise généralement la protection de la mémoire et la mémoire virtuelle et peut également gérer un accès mémoire non uniforme , mais le projet a absorbé μClinux qui permet également d'exécuter Linux sur des microcontrôleurs sans mémoire virtuelle.

Le matériel est représenté dans la hiérarchie des fichiers. Les applications utilisateur interagissent avec les pilotes de périphérique via des entrées dans les répertoires /dev ou /sys . Les informations sur les processus sont également mappées au système de fichiers via le répertoire /proc .

Diverses couches au sein de Linux, montrant également la séparation entre l' espace utilisateur et l' espace noyau
Mode utilisateur Candidatures utilisateur bash , LibreOffice , GIMP , Blender , 0 AD , Mozilla Firefox , ...
Composants du système Démons :
systemd , runit , udevd , polkitd , sshd , smbd ...
Gestionnaire de fenêtres :
X11 , Wayland , SurfaceFlinger (Android)
Graphiques :
Mesa , AMD Catalyst , ...
Autres bibliothèques :
GTK , Qt , EFL , SDL , SFML , FLTK , GNUstep , ...
bibliothèque standard C fopen, , execv, malloc, memcpy, localtime, pthread_create... (jusqu'à 2000 sous-routines )
glibc vise à être rapide, musl et uClibc ciblent les systèmes embarqués, bionic écrit pour Android , etc. Tous visent à être compatibles POSIX / SUS .
Mode noyau Noyau Linux stat, splice, dup, read, open, ioctl, write, mmap, close, exit, etc. (environ 380 appels système)
L' interface d'appel système du noyau Linux (SCI, vise à être compatible POSIX / SUS )

Sous-système de planification de processus

Sous-système IPC

Sous-système de gestion de la mémoire

Sous-système de fichiers virtuels

Sous - système réseau
Autres composants : ALSA , DRI , evdev , LVM , mappeur de périphériques , Linux Network Scheduler , Netfilter
Linux Security Modules : SELinux , TOMOYO , AppArmor , Smack
Matériel ( CPU , mémoire principale , périphériques de stockage de données , etc.)

Interfaces

Quatre interfaces sont distinguées : deux internes au noyau, et deux entre le noyau et l'espace utilisateur.

Linux est un clone d'UNIX et vise la conformité POSIX et Single UNIX Specification . Le noyau fournit également des appels système et d'autres interfaces spécifiques à Linux. Pour être inclus dans le noyau officiel, le code doit être conforme à un ensemble de règles de licence.

L' interface binaire d'application Linux (ABI) entre le noyau et l'espace utilisateur a quatre degrés de stabilité (stable, test, obsolète, supprimé) ; cependant, les appels système ne devraient jamais changer afin de ne pas casser les programmes de l' espace utilisateur qui en dépendent.

Les modules de noyau chargeables (LKM), de par leur conception, ne peuvent pas s'appuyer sur une ABI stable. Par conséquent, ils doivent toujours être recompilés chaque fois qu'un nouvel exécutable du noyau est installé dans un système, sinon ils ne seront pas chargés. Les pilotes in-tree qui sont configurés pour devenir une partie intégrante de l'exécutable du noyau ( vmlinux ) sont liés de manière statique par le processus de construction.

Il n'y a pas non plus de garantie de stabilité de l'API in-kernel au niveau de la source et, à cause de cela, le code des pilotes de périphériques , ainsi que le code de tout autre sous-système du noyau, doit être mis à jour avec l'évolution du noyau. Tout développeur qui modifie l'API est tenu de corriger tout code qui se brise à la suite de sa modification.

API du noyau vers l'espace utilisateur

L'ensemble de l' API du noyau Linux qui concerne les interfaces exposées aux applications utilisateur est fondamentalement composé d' appels système spécifiques à UNIX et Linux . Un appel système est un point d'entrée dans le noyau Linux. Par exemple, parmi ceux spécifiques à Linux, il y a la famille des appels système clone(2) . La plupart des extensions doivent être activées en définissant la _GNU_SOURCE macro dans un fichier d' en- tête ou lors de la compilation du code utilisateur.

Les appels système ne peuvent être invoqués qu'à l'aide d'instructions d'assemblage qui permettent la transition d'un espace utilisateur non privilégié vers un espace noyau privilégié dans l' anneau 0 . Pour cette raison, la bibliothèque standard C (libC) agit comme un wrapper pour la plupart des appels système Linux, en exposant des fonctions C qui, uniquement si elles sont nécessaires, peuvent entrer de manière transparente dans le noyau qui s'exécutera au nom du processus appelant. Pour les appels système non exposés par libC, par exemple le mutex rapide de l'espace utilisateur ( futex ), la bibliothèque fournit une fonction appelée syscall(2) qui peut être utilisée pour les invoquer explicitement.

Les pseudo-systèmes de fichiers (par exemple, les systèmes de fichiers sysfs et procfs ) et les fichiers spéciaux (par exemple, /dev/random, /dev/sda, /dev/tty, et bien d'autres) constituent une autre couche d'interface avec les structures de données du noyau représentant des périphériques matériels ou logiques (logiciels).

ABI du noyau vers l'espace utilisateur

En raison des différences existant entre les centaines d'implémentations diverses du système d'exploitation Linux, les objets exécutables, même s'ils sont compilés, assemblés et liés pour s'exécuter sur une architecture matérielle spécifique (c'est-à-dire qu'ils utilisent l' ISA du matériel cible), ne peut souvent pas fonctionner sur différentes distributions Linux. Ce problème est principalement dû aux configurations spécifiques à la distribution et à un ensemble de correctifs appliqués au code du noyau Linux, aux différences dans les bibliothèques système, les services (démons), les hiérarchies de systèmes de fichiers et les variables d'environnement.

La principale norme concernant les applications et la compatibilité binaire des distributions Linux est la Linux Standard Base (LSB). Cependant, le LSB va au-delà de ce qui concerne le noyau Linux, car il définit aussi les spécifications du bureau, les bibliothèques X et Qt qui n'y sont pour rien. La version 5 de LSB est basée sur plusieurs normes et versions préliminaires (POSIX, SUS, X/Open, File System Hierarchy (FHS) et autres).

Les parties du LSB largement pertinentes pour le noyau sont l' ABI générale (gABI), en particulier l' ABI System V et le format exécutable et de liaison (ELF), et l' ABI spécifique au processeur (psABI), par exemple la spécification de base pour X86- 64.

L'ABI standard sur la façon dont les programmes utilisateur x86_64 appellent les appels système consiste à charger le numéro syscall dans le registre rax et les autres paramètres dans rdi , rsi , rdx , r10 , r8 et r9 , et enfin à mettre l' instruction d'assemblage syscall dans le code.

API dans le noyau

Lors du XDC2014, Alex Deucher d'AMD a annoncé le pilote en mode noyau unifié. Le pilote graphique propriétaire Linux, libGL-fglrx-glx , partagera la même infrastructure DRM avec Mesa 3D . Comme il n'y a pas d' ABI stable dans le noyau , AMD a dû constamment adapter l'ancien blob binaire utilisé par Catalyst.

Il existe plusieurs API internes au noyau utilisées entre les différents sous-systèmes. Certains ne sont disponibles que dans les sous-systèmes du noyau, tandis qu'un ensemble quelque peu limité de symboles dans le noyau (c'est-à-dire des variables, des structures de données et des fonctions) est également exposé à des modules chargeables dynamiquement (par exemple, des pilotes de périphériques chargés à la demande), qu'ils soient exporté avec les macros EXPORT_SYMBOL() et EXPORT_SYMBOL_GPL() (cette dernière réservée aux modules publiés sous licence compatible GPL).

Linux fournit des API dans le noyau qui manipulent des structures de données (par exemple, les listes chaînées , arbres Radix , arbres rouges-noirs , files d' attente ) ou exécuter des routines communes (par exemple, copier des données depuis et vers l' espace utilisateur, allouer de la mémoire, des lignes d'impression dans le journal du système , et ainsi de suite) qui sont restés stables au moins depuis la version 2.6 de Linux.

Les API intégrées au noyau incluent des bibliothèques de services communs de bas niveau utilisés par les pilotes de périphérique :

  • Interfaces SCSI et libATA  - respectivement, un protocole de communication peer-to-peer basé sur des paquets pour les périphériques de stockage connectés à USB, SATA, SAS, Fibre Channel, FireWire, périphérique ATAPI et une bibliothèque dans le noyau pour prendre en charge les contrôleurs hôtes [S]ATA et appareils.
  • Direct Rendering Manager (DRM) et Kernel Mode Setting (KMS) - pour l'interfaçage avec les GPU et la prise en charge des besoins du matériel vidéo moderne accéléré en 3D, et pour le réglage de la résolution de l'écran, de la profondeur des couleurs et du taux de rafraîchissement
  • Tampons DMA ( DMA-BUF ) - pour partager des tampons pour un accès direct à la mémoire matérielle entre plusieurs pilotes de périphériques et sous-systèmes
  • Video4Linux  – pour le matériel de capture vidéo
  • Advanced Linux Sound Architecture (ALSA) – pour les cartes son
  • Nouvelle API  - pour les contrôleurs d'interface réseau
  • mac80211  - pour les contrôleurs d'interface réseau sans fil

ABI dans le noyau

Les développeurs Linux choisissent de ne pas maintenir une ABI stable dans le noyau. Les modules compilés pour une version spécifique du noyau ne peuvent pas être chargés dans une autre version sans être recompilés, en supposant que l'API in-kernel au niveau source est restée la même, sinon le code du module doit également être modifié en conséquence.

Processus et threads

Linux crée des processus au moyen de clone(2) ou par les nouveaux appels système clone3(2) . Selon les paramètres donnés, la nouvelle entité peut partager la plupart ou aucune des ressources de l'appelant. Ces appels système peuvent créer de nouvelles entités allant de nouveaux processus indépendants (chacun ayant un identifiant spécial appelé TGID dans la structure de données task_struct dans l'espace noyau, bien que ce même identifiant soit appelé PID dans l'espace utilisateur), à de nouveaux threads d'exécution au sein du processus appelant (par à l'aide du paramètre CLONE_THREAD ). Dans ce dernier cas, la nouvelle entité possède le même TGID du processus appelant et a par conséquent également le même PID dans l'espace utilisateur.

Si l'exécutable est lié dynamiquement à des bibliothèques partagées, un éditeur de liens dynamique (pour les objets ELF, il s'agit généralement de /lib/ld-linux.so.2 ) est utilisé pour rechercher et charger les objets nécessaires, préparer le programme à s'exécuter puis exécuter ce.

La bibliothèque de Native POSIX Thread , simplement connu sous le nom NPTL, fournit l'interface threads POSIX standard ( pthreads ) vers l' espace utilisateur chaque fois qu'un nouveau thread est créé en utilisant l'interface POSIX pthread_create (3), le clone (2) la famille des appels système doit également être étant donné l'adresse de la fonction vers laquelle le nouveau thread doit sauter. Le noyau Linux fournit les mécanismes futex(7) (acronyme de "Fast user-space mutexes") pour un verrouillage et une synchronisation rapides de l'espace utilisateur ; la majorité des opérations sont effectuées en espace utilisateur mais il peut être nécessaire de communiquer avec le noyau en utilisant l' appel système futex(2) .

Une catégorie très spéciale de threads est ce qu'on appelle les threads du noyau . Ils ne doivent pas être confondus avec les fils d'exécution des processus de l'utilisateur mentionnés ci-dessus. Les threads du noyau n'existent que dans l'espace noyau et leur seul objectif est d'exécuter simultanément des tâches du noyau.

Différemment, chaque fois qu'un processus indépendant est créé, les appels système retournent exactement à l'instruction suivante du même programme, simultanément dans le processus parent et dans celui de l' enfant (c'est-à-dire un programme, deux processus). Différentes valeurs de retour (une par processus) permettent au programme de savoir dans lequel des deux processus il s'exécute actuellement. Les programmes ont besoin de ces informations car le processus fils, quelques étapes après la duplication du processus, invoque généralement l'appel système execve(2) (éventuellement via la famille de fonctions wrapper exec(3) dans la glibC) et remplace le programme en cours d'exécution par le processus appelant avec un nouveau programme, avec une pile, un tas et des segments de données (initialisés et non initialisés) nouvellement initialisés. Quand c'est fait, il en résulte deux processus qui exécutent deux programmes différents.

En fonction de l' ID utilisateur effectif ( euid ) et de l' ID de groupe effectif ( egid ), un processus exécuté avec les privilèges de l'utilisateur zéro ( root , l'administrateur système, possède l'identifiant 0) peut tout effectuer (par exemple, tuer tous les autres processus ou effacer récursivement des systèmes de fichiers entiers), au lieu de cela, les processus utilisateur non nuls ne le peuvent pas. capacités(7) divise les privilèges traditionnellement associés au superutilisateur en unités distinctes, qui peuvent être indépendamment activées et désactivées par le processus parent ou supprimées par l'enfant lui-même.

Ordonnancement et préemption

L'ordonnanceur Linux est modulaire, dans le sens où il permet différentes classes et politiques d'ordonnancement. Les classes de planificateur sont des algorithmes de planificateur enfichables qui peuvent être enregistrés avec le code du planificateur de base. Chaque classe programme différents types de processus. Le code de base du planificateur parcourt chaque classe par ordre de priorité et choisit le planificateur de priorité la plus élevée qui a une entité planifiable de type struct sched_entity prête à être exécutée. Les entités peuvent être des threads, des groupes de threads et même tous les processus d'un utilisateur spécifique.

Linux fournit à la fois la préemption de l'utilisateur et la préemption complète du noyau . La préemption réduit la latence , augmente la réactivité et rend Linux plus adapté aux applications de bureau et en temps réel.

Pour les tâches normales, par défaut, le noyau utilise la classe Completely Fair Scheduler (CFS), introduite dans la version 2.6.23 du noyau. En interne, cette classe de planificateur par défaut est définie dans une macro d'un en-tête C en tant que SCHED_NORMAL. Dans d'autres noyaux POSIX, une politique similaire connue sous le nom d' SCHED_OTHERallocation de tranches de temps CPU (c'est-à-dire qu'elle attribue des tranches absolues de temps processeur en fonction de la priorité prédéterminée ou calculée dynamiquement de chaque processus). Le CFS Linux supprime les tranches de temps absolues et attribue une bonne proportion de temps CPU, en fonction de paramètres tels que le nombre total de processus exécutables et le temps qu'ils ont déjà exécuté ; cette fonction prend également en compte une sorte de poids qui dépend de leurs priorités relatives (valeurs sympas).

Avec la préemption de l'utilisateur, l'ordonnanceur du noyau peut remplacer le processus en cours par l'exécution d'un changement de contexte vers un autre qui acquiert donc les ressources de calcul pour l'exécution (CPU, mémoire, etc.). Il le fait selon l' algorithme CFS (en particulier, il utilise une variable appelée vruntime pour trier les entités, puis choisit celle qui a le plus petit vruntime, c'est-à-dire l'entité planifiable qui a eu le moins de temps CPU), pour la politique active de l'ordonnanceur et aux priorités relatives. Avec la préemption du noyau, le noyau peut se préempter lorsqu'un gestionnaire d'interruption revient, lorsque les tâches du noyau se bloquent et chaque fois qu'un sous-système appelle explicitement la fonction schedule().

Le noyau contient également deux classes de planification en temps réel compatibles POSIX nommées SCHED_FIFO(realtime first-in-first-out ) et SCHED_RR(realtime round-robin ), qui ont toutes deux la priorité sur la classe par défaut. Une politique d'ordonnancement supplémentaire connue sous le nom de SCHED DEADLINE, implémentant le premier algorithme d'échéance (EDF), a été ajoutée dans la version 3.14 du noyau, publiée le 30 mars 2014. SCHED_DEADLINEa la priorité sur toutes les autres classes d'ordonnancement.

Le correctif du noyau Linux PREEMPT_RTpermet une préemption complète des sections critiques, des gestionnaires d'interruption et des séquences de code de « désactivation d'interruption ». L'intégration partielle des correctifs Linux en temps réel a apporté la fonctionnalité mentionnée ci-dessus à la ligne principale du noyau.

Concurrence et synchronisation

Le noyau a différentes causes de concurrence (par exemple, les interruptions, les moitiés inférieures, la préemption des tâches du noyau et des utilisateurs, le multitraitement symétrique). Pour protéger les régions critiques (sections de code qui doivent être exécutées de manière atomique), les emplacements de mémoire partagée (comme les variables globales et autres structures de données avec une portée globale) et les régions de mémoire qui sont modifiables de manière asynchrone par le matériel (par exemple, ayant le qualificateur de type C ) , Linux fournit un large éventail d'outils. Ils se composent de types atomiques (qui ne peuvent être manipulés que par un ensemble d'opérateurs spécifiques), de verrous d'attente , de sémaphores , de mutex et d' algorithmes sans verrou (par exemple, les RCU ). La plupart des algorithmes sans verrouillage sont construits sur des barrières de mémoire dans le but d'appliquer l' ordre de la mémoire et d'éviter les effets secondaires indésirables dus aux optimisations du compilateur . volatile

Gestion des interruptions

La gestion des interruptions , bien qu'elle puisse être considérée comme un seul travail, est divisée en deux parties distinctes. Cette scission en deux est due aux contraintes de temps différentes et aux besoins de synchronisation des tâches dont la gestion est composée. La première partie est composée d'une routine de service d'interruption asynchrone qui, sous Linux, est connue sous le nom de moitié supérieure , tandis que la seconde partie est exécutée par l'un des trois types de moitiés dites inférieures ( softirq , tasklets et files d'attente de travail ) . Les routines de service d'interruptions Linux peuvent être imbriquées (c'est-à-dire qu'une nouvelle IRQ peut piéger dans un ISR de haute priorité qui préempte tout autre ISR de priorité inférieure).

Gestion de la mémoire

La gestion de la mémoire sous Linux est un sujet complexe. Tout d'abord, le noyau n'est pas paginable (c'est-à-dire qu'il réside toujours dans la mémoire physique et ne peut pas être échangé sur le disque). Dans le noyau, il n'y a pas de protection de la mémoire (pas de signaux SIGSEGV , contrairement à l'espace utilisateur), donc les violations de mémoire entraînent une instabilité et des plantages du système.

Linux implémente la mémoire virtuelle avec des tables de pages à 4 et 5 niveaux . Comme dit, seul l'espace mémoire de l'utilisateur est toujours paginable . Il conserve des informations sur chaque cadre de page de RAM dans des structures de données appropriées (de type struct page ) qui sont remplies immédiatement après le démarrage et qui sont conservées jusqu'à l'arrêt, qu'elles soient ou non associées à des pages virtuelles. De plus, il classe tous les cadres de page en zones, en fonction de leurs contraintes dépendant de l'architecture et de l'utilisation prévue. Par exemple, les pages réservées aux opérations DMA sont dans ZONE_DMA, les pages qui ne sont pas mappées de manière permanente sur des adresses virtuelles sont dans ZONE_HIGHMEM (dans l'architecture x86_32, cette zone est destinée aux adresses physiques supérieures à 896 Mo, tandis que x86_64 n'en a pas besoin car x86_64 peut mapper de manière permanente pages qui résident dans des adresses plus élevées), et tout ce qui reste (à l'exception d'autres classifications moins utilisées) est dans ZONE_NORMAL.

De petits morceaux de mémoire peuvent être alloués dynamiquement via la famille d' kmalloc()API et libérés avec la variante appropriée de kfree(). vmalloc()et kvfree()sont utilisés pour les gros morceaux pratiquement contigus. alloc_pages() alloue le nombre souhaité de pages entières.

Le diagramme de pile de stockage Linux

Architectures prises en charge

TiVo DVR , un appareil grand public fonctionnant sous Linux

Bien qu'il n'ait pas été conçu à l'origine pour être portable , Linux est aujourd'hui l'un des noyaux de système d'exploitation les plus largement portés, s'exécutant sur une gamme variée de systèmes allant de l' architecture ARM aux ordinateurs centraux IBM z/Architecture . Le premier portage a été effectué sur la plate-forme Motorola 68000 . Les modifications apportées au noyau étaient si fondamentales que Torvalds considérait la version Motorola comme un fork et un "système d'exploitation de type Linux". Cependant, cela a poussé Torvalds à mener une restructuration majeure du code pour faciliter le portage vers davantage d'architectures informatiques. Le premier Linux qui, dans une seule arborescence source, avait du code pour plus que i386 seul, prenait en charge la plate-forme DEC Alpha AXP 64 bits.

Linux fonctionne comme système d'exploitation principal sur IBM 's Summit ; en octobre 2019, tous les 500 supercalculateurs les plus rapides au monde exécutaient un système d'exploitation basé sur le noyau Linux, un grand changement par rapport à 1998, lorsque le premier supercalculateur Linux a été ajouté à la liste.

Linux a également été porté sur divers appareils portables tels que l' iPhone 3G et l' iPod d' Apple .

Périphériques compatibles

En 2007, le projet LKDDb a été lancé pour construire une base de données complète du matériel et des protocoles connus par les noyaux Linux. La base de données est construite automatiquement par analyse statique des sources du noyau. Plus tard en 2014, le projet Linux Hardware a été lancé pour collecter automatiquement une base de données de toutes les configurations matérielles testées avec l'aide des utilisateurs de diverses distributions Linux.

Patch en direct

Les mises à jour sans redémarrage peuvent même être appliquées au noyau en utilisant des technologies de patch en direct telles que Ksplice , kpatch et kGraft . Les fondations minimalistes pour le patching du noyau en direct ont été fusionnées dans la ligne principale du noyau Linux dans la version 4.0 du noyau, qui a été publiée le 12 avril 2015. Ces fondations, connues sous le nom de livepatch et basées principalement sur la fonctionnalité ftrace du noyau , forment un noyau commun capable de prendre en charge les correctifs à chaud. par kGraft et kpatch, en fournissant une interface de programmation d'application (API) pour les modules du noyau qui contiennent des correctifs et une interface binaire d'application (ABI) pour les utilitaires de gestion de l'espace utilisateur. Cependant, le noyau commun inclus dans le noyau Linux 4.0 ne prend en charge que l' architecture x86 et ne fournit aucun mécanisme pour assurer la cohérence au niveau des fonctions pendant que les correctifs à chaud sont appliqués. Depuis avril 2015, des travaux sont en cours sur le portage de kpatch et kGraft vers le noyau commun de correctifs en direct fourni par la ligne principale du noyau Linux.

Sécurité

Les bogues du noyau présentent des problèmes de sécurité potentiels. Par exemple, ils peuvent permettre une élévation des privilèges ou créer des vecteurs d' attaque par déni de service . Au fil des ans, de nombreux bogues affectant la sécurité du système ont été trouvés et corrigés. De nouvelles fonctionnalités sont fréquemment implémentées pour améliorer la sécurité du noyau.

Les capacités(7) ont déjà été introduites dans la section sur les processus et les threads. Android les utilise et systemd donne aux administrateurs un contrôle détaillé sur les capacités des processus.

Linux offre une multitude de mécanismes pour réduire la surface d'attaque du noyau et améliorer la sécurité, qui sont collectivement connus sous le nom de Linux Security Modules (LSM). Ils comprennent le module Security-Enhanced Linux (SELinux), dont le code a été initialement développé puis rendu public par la NSA , et AppArmor entre autres. SELinux est maintenant activement développé et maintenu sur GitHub . SELinux et AppArmor prennent en charge les politiques de sécurité du contrôle d'accès, y compris le contrôle d'accès obligatoire (MAC), bien qu'elles diffèrent profondément en termes de complexité et de portée.

Une autre fonctionnalité de sécurité est le Seccomp BPF (SECure COMPuting with Berkeley Packet Filters) qui fonctionne en filtrant les paramètres et en réduisant l'ensemble des appels système disponibles pour les applications utilisateur.

Les critiques ont accusé les développeurs du noyau de dissimuler des failles de sécurité, ou du moins de ne pas les annoncer ; en 2008, Linus Torvalds a répondu à ceci avec ce qui suit :

Personnellement, je considère que les bogues de sécurité ne sont que des "bogues normaux". Je ne les dissimule pas, mais je n'ai aucune raison non plus de penser que c'est une bonne idée de les suivre et de les annoncer comme quelque chose de spécial... une raison pour laquelle je refuse de m'embêter avec toute la sécurité cirque, c'est que je pense qu'il glorifie - et encourage ainsi - le mauvais comportement. Cela fait des "héros" des personnes chargées de la sécurité, comme si les personnes qui ne se contentent pas de corriger les bogues normaux n'étaient pas aussi importantes. En fait, tous les bogues normaux ennuyeux sont bien plus importants, simplement parce qu'il y en a beaucoup plus. Je ne pense pas qu'un trou de sécurité spectaculaire doive être glorifié ou considéré comme étant plus "spécial" qu'un crash spectaculaire aléatoire dû à un mauvais verrouillage.

Les distributions Linux publient généralement des mises à jour de sécurité pour corriger les vulnérabilités du noyau Linux. Beaucoup proposent des versions de support à long terme qui reçoivent des mises à jour de sécurité pour une certaine version du noyau Linux pendant une période prolongée.

Développement

Rien
Inconnu
Conseillers
SUSE
Google
autres
entreprises


Principaux contributeurs au noyau par entreprise en 2017.

Communauté de développeurs

La communauté des développeurs du noyau Linux comprend environ 5 000 à 6 000 membres. Selon « 2017 State of Linux Kernel Development », une étude publiée par la Linux Foundation, couvrant les engagements pour les versions 4.8 à 4.13, environ 1500 développeurs ont contribué en moyenne à environ 200-250 entreprises. Les 30 meilleurs développeurs ont contribué un peu plus de 16% du code. Du côté des entreprises, les principaux contributeurs sont Intel (13,1 %) et Red Hat (7,2 %), Linaro (5,6 %), IBM (4,1 %), les deuxième et cinquième places sont occupées par le « aucun » (8,2 %) et catégories « inconnu » (4,1 %).

Au lieu d'une feuille de route, il existe des directives techniques. Au lieu d'une allocation de ressources centrale, il y a des personnes et des entreprises qui ont toutes un intérêt dans le développement ultérieur du noyau Linux, tout à fait indépendamment les unes des autres : des gens comme Linus Torvalds et moi ne planifions pas l'évolution du noyau. Nous ne restons pas assis là et réfléchissons à la feuille de route pour les deux prochaines années, puis affectons des ressources aux différentes nouvelles fonctionnalités. C'est parce que nous n'avons pas de ressources. Les ressources appartiennent toutes aux diverses sociétés qui utilisent et contribuent à Linux, ainsi qu'aux divers contributeurs indépendants. Ce sont les personnes qui possèdent les ressources qui décident...

-  Andrew Morton , 2005

Comme pour de nombreux grands projets de logiciels open source, les développeurs sont tenus d'adhérer au Contributor Covenant , un code de conduite destiné à lutter contre le harcèlement des contributeurs minoritaires.

Gestion des codes sources

La communauté de développement Linux utilise Git pour gérer le code source . Les utilisateurs de Git clonent la dernière version de l'arbre de Torvalds avec git-clone(1) et la maintiennent à jour en utilisant git-pull(1) . Les contributions sont soumises sous forme de correctifs, sous forme de messages texte sur le LKML (et souvent aussi sur d'autres listes de diffusion dédiées à des sous-systèmes particuliers). Les correctifs doivent se conformer à un ensemble de règles et à un langage formel qui, entre autres, décrit quelles lignes de code doivent être supprimées et quelles autres doivent être ajoutées aux fichiers spécifiés. Ces correctifs peuvent être traités automatiquement afin que les administrateurs système puissent les appliquer afin d'apporter quelques modifications au code ou de passer progressivement à la version suivante. Linux est également distribué aux formats GNU zip (gzip) et bzip2 .

Soumettre du code au noyau

Un développeur qui souhaite changer le noyau Linux commence par développer et tester ce changement. En fonction de l'importance de la modification et du nombre de sous-systèmes qu'elle modifie, la modification sera soit soumise sous la forme d'un seul correctif, soit dans plusieurs correctifs de code source . Dans le cas d'un seul sous-système maintenu par un seul responsable, ces correctifs sont envoyés sous forme d'e-mails au responsable du sous-système avec la liste de diffusion appropriée dans Cc. Le mainteneur et les lecteurs de la liste de diffusion examineront les correctifs et fourniront leurs commentaires. Une fois le processus de révision terminé, le mainteneur du sous-système accepte les correctifs dans l' arborescence du noyau Git appropriée . Si les modifications apportées au noyau Linux sont des corrections de bogues considérées comme suffisamment importantes, une demande d'extraction pour les correctifs sera envoyée à Torvalds dans quelques jours. Sinon, une pull request sera envoyée à Torvalds lors de la prochaine fenêtre de fusion. La fenêtre de fusion dure généralement deux semaines et démarre immédiatement après la publication de la version précédente du noyau. L'arborescence des sources du noyau Git nomme tous les développeurs qui ont contribué au noyau Linux dans le répertoire Crédits et tous les responsables de sous-système sont répertoriés dans Mainteneurs .

Langage de programmation et style de codage

Linux est écrit dans un langage de programmation C spécial pris en charge par GCC , un compilateur qui étend à bien des égards le standard C, par exemple en utilisant des sections de code en ligne écrites en langage assembleur (dans la syntaxe "AT&T-style" de GCC) de l'architecture cible . Depuis 2002, tout le code doit respecter les 21 règles constituant le style de codage du noyau Linux.

Chaîne d'outils GNU

La collection de compilateurs GNU (GCC ou GNU cc) est le compilateur par défaut pour les sources Linux principales et il est invoqué par un utilitaire appelé make . Ensuite, l' assembleur GNU (plus souvent appelé GAS ou GNU as) sort les fichiers objets à partir du code assembleur généré par GCC . Enfin, GNU Linker (GNU ld) est utilisé pour produire un fichier de noyau exécutable lié de manière statique appelé vmlinux . Les deux comme et ld font partie de GNU Binary Utilities (binutils). Les outils mentionnés ci-dessus sont collectivement connus sous le nom de chaîne d'outils GNU .

Compilation compilateur

GCC a longtemps été le seul compilateur capable de construire correctement Linux. En 2004, Intel a affirmé avoir modifié le noyau afin que son compilateur C soit également capable de le compiler. Il y a eu un autre succès de ce type en 2009, avec une version 2.6.22 modifiée.

Depuis 2010, des efforts sont en cours pour construire Linux avec Clang , un compilateur alternatif pour le langage C ; au 12 avril 2014, le noyau officiel pouvait presque être compilé par Clang. Le projet dédié à cet effort est nommé LLVMLinux d' après l' infrastructure du compilateur LLVM sur laquelle Clang est construit. LLVMLinux n'a pas pour objectif de bifurquer ni Linux ni le LLVM, il s'agit donc d'un méta-projet composé de correctifs qui sont éventuellement soumis aux projets en amont. En permettant à Linux d'être compilé par Clang, les développeurs peuvent bénéficier de temps de compilation plus courts.

En 2017, les développeurs ont terminé les correctifs en amont pour prendre en charge la construction du noyau Linux avec Clang dans la version 4.15, ayant rétroporté la prise en charge de X86-64 et AArch64 vers les branches 4.4, 4.9 et 4.14 de l'arborescence du noyau stable. Le Pixel 2 de Google a été livré avec le premier noyau Linux construit par Clang , bien que des correctifs pour Pixel (1ère génération) aient existé. 2018 a vu ChromeOS passer à la construction de noyaux avec Clang par défaut, tandis qu'Android (système d'exploitation) a rendu Clang et LLD de liaison de LLVM requis pour les versions de noyau en 2019. Google a déplacé son noyau de production utilisé dans ses centres de données pour être construit avec Clang en 2020. Aujourd'hui, le groupe ClangBuiltLinux coordonne les correctifs à la fois pour Linux et LLVM pour assurer la compatibilité, tous deux composés de membres de LLVMLinux et ayant des correctifs en amont de LLVMLinux .

Débogage du noyau

Un exemple de panique du noyau Linux

Les bogues impliquant le noyau Linux peuvent être difficiles à résoudre. C'est à cause de l'interaction du noyau avec l'espace utilisateur et le matériel ; et aussi parce qu'ils peuvent être causés par un plus large éventail de raisons par rapport à celles des programmes utilisateur. Quelques exemples des causes sous-jacentes sont des erreurs sémantiques dans le code, une mauvaise utilisation des primitives de synchronisation et une gestion matérielle incorrecte.

Un rapport d'un bogue non fatal dans le noyau s'appelle un « oups » ; de tels écarts par rapport au comportement correct du noyau Linux peuvent permettre un fonctionnement continu avec une fiabilité compromise.

Une erreur critique et fatale est signalée via la fonction panic() . Il imprime un message puis arrête le noyau.

L'une des techniques les plus couramment utilisées pour détecter les bogues dans le code est le débogage par impression . À cette fin, Linux fournit une API intégrée au noyau appelée printk () qui stocke les messages dans un tampon circulaire. L' appel système syslog(2) est utilisé pour lire et/ou effacer le tampon en anneau des messages du noyau et pour définir le niveau de journalisation maximum des messages à envoyer à la console (c'est-à-dire l'un des huit paramètres KERN_* de printk() , qui indiquent la gravité de l'affection signalée); généralement, il est invoqué via le wrapper glibC klogctl(3) . Les messages du noyau sont également exportés vers l'espace utilisateur via l' interface /dev/kmsg (par exemple, systemd-journald lit cette interface et ajoute par défaut les messages à /var/log/journal ).

Une autre technique fondamentale pour déboguer un noyau en cours d'exécution est le traçage. Le mécanisme ftrace est un traceur interne Linux ; il est utilisé pour surveiller et déboguer Linux au moment de l'exécution et il peut également analyser les latences de l'espace utilisateur dues à un mauvais comportement du noyau. De plus, ftrace permet aux utilisateurs de tracer Linux au démarrage.

kprobes et kretprobes peuvent s'introduire (comme les débogueurs dans l'espace utilisateur) dans Linux et collecter des informations sans interruption. Les kprobes peuvent être insérés dans le code à (presque) n'importe quelle adresse, tandis que les kretprobes fonctionnent au retour de fonction. Les uprobes ont des objectifs similaires, mais elles présentent également des différences d'utilisation et de mise en œuvre.

Avec KGDB, Linux peut être débogué de la même manière que les programmes en espace utilisateur. KGDB nécessite une machine supplémentaire qui exécute GDB et qui est connectée à la cible à déboguer à l'aide d'un câble série ou Ethernet .

Modèle de développement

Le projet de noyau Linux intègre du nouveau code sur une base continue. Le logiciel enregistré dans le projet doit fonctionner et compiler sans erreur. Chaque sous-système du noyau se voit attribuer un mainteneur qui est responsable de la révision des correctifs par rapport aux normes du code du noyau et conserve une file d'attente de correctifs qui peuvent être soumis à Linus Torvalds dans une fenêtre de fusion de plusieurs semaines. Les correctifs sont fusionnés par Torvalds dans le code source de la précédente version stable du noyau Linux, créant la version candidate -rc pour le prochain noyau stable. Une fois la fenêtre de fusion fermée, seuls les correctifs du nouveau code de la version de développement sont acceptés. La version de développement -rc du noyau passe par des tests de régression et une fois qu'elle est jugée stable par Torvalds et les mainteneurs du sous-système du noyau, un nouveau noyau Linux est publié et le processus de développement recommence.

Les développeurs qui se sentent traités injustement peuvent le signaler au comité consultatif technique de la Linux Foundation . En juillet 2013, le mainteneur du pilote USB 3.0 Sage Sharp a demandé à Torvalds de répondre aux commentaires abusifs de la communauté de développement du noyau. En 2014, Sharp s'est retiré du développement du noyau Linux, déclarant que « L'accent mis sur l'excellence technique, en combinaison avec des mainteneurs surchargés et des personnes ayant des normes culturelles et sociales différentes, signifie que les mainteneurs du noyau Linux sont souvent directs, grossiers ou brutaux à obtenir. leur travail est fait". Lors de la conférence linux.conf.au (LCA) en 2018, les développeurs ont exprimé l'avis que la culture de la communauté s'est beaucoup améliorée au cours des dernières années. Daniel Vetter, le mainteneur du pilote du noyau graphique Intel drm/i915, a déclaré que le "langage et la discussion plutôt violents" dans la communauté du noyau ont diminué ou ont disparu.

Laurent Pinchart a demandé aux développeurs de commenter leur expérience avec la communauté du noyau lors de l'Embedded Linux Conference Europe 2017. Les problèmes soulevés ont été discutés quelques jours plus tard lors du sommet des mainteneurs. Les inquiétudes concernant le manque de cohérence dans la façon dont les responsables ont répondu aux correctifs soumis par les développeurs ont été reprises par Shuah Khan , le responsable du framework d'auto-test du noyau. Torvalds a soutenu qu'il n'y aurait jamais de cohérence dans la gestion des correctifs car différents sous-systèmes du noyau ont, au fil du temps, adopté des processus de développement différents. Par conséquent, il a été convenu que chaque mainteneur de sous-système du noyau documenterait les règles d'acceptation des correctifs.

Linux principal

L' arbre Git de Linus Torvalds qui contient le noyau Linux est appelé Linux principal . Chaque version stable du noyau provient de l'arborescence principale et est fréquemment publiée sur kernel.org . Mainline Linux n'a un support solide que pour un petit sous-ensemble des nombreux appareils qui exécutent Linux. Le support non principal est fourni par des projets indépendants, tels que Yocto ou Linaro , mais dans de nombreux cas, le noyau du fournisseur de périphériques est nécessaire. L'utilisation d'un noyau de fournisseur nécessite probablement un package de support de carte .

Maintenir une arborescence de noyau en dehors de Linux principal s'est avéré difficile.

Mainlining fait référence à l'effort d'ajouter la prise en charge d'un périphérique au noyau principal, alors qu'auparavant, il n'y avait qu'une prise en charge dans un fork ou aucune prise en charge du tout. Cela inclut généralement l'ajout de pilotes ou de fichiers d' arborescence de périphériques . Une fois cette opération terminée, la fonctionnalité ou le correctif de sécurité est considéré comme principal .

Noyau de type Linux

Le mainteneur de la branche stable, Greg Kroah-Hartman , a appliqué le terme de type Linux aux fourches du noyau en aval par les fournisseurs qui ajoutent des millions de lignes de code au noyau principal. En 2019, Google a déclaré vouloir utiliser le noyau Linux principal dans Android afin de réduire le nombre de fourches du noyau. Le terme de type Linux a également été appliqué au sous-ensemble du noyau Linux intégrable , qui n'inclut pas le noyau Linux principal complet mais un petit sous-ensemble modifié du code.

fourches Linux

Un iPod démarrant iPodLinux

Il existe certaines communautés qui développent des noyaux basés sur le Linux officiel. Certains morceaux de code intéressants de ces forks (c'est-à-dire un terme d'argot signifiant "projets dérivés") qui incluent Linux-libre , Compute Node Linux , INK , L4Linux , RTLinux et User-Mode Linux (UML) ont été fusionnés dans la ligne principale . Certains systèmes d'exploitation développés pour les téléphones mobiles utilisaient initialement des versions fortement modifiées de Linux, notamment Google Android , Firefox OS , HP webOS , Nokia Maemo et Jolla Sailfish OS . En 2010, la communauté Linux a critiqué Google pour avoir effectivement démarré son propre arbre de noyau :

Cela signifie que tous les pilotes écrits pour les plates-formes matérielles Android ne peuvent pas être fusionnés dans l'arborescence principale du noyau car ils ont des dépendances sur le code qui ne réside que dans l'arborescence du noyau de Google, ce qui l'empêche de se construire dans l'arborescence kernel.org. Pour cette raison, Google a maintenant empêché qu'une grande partie des pilotes matériels et du code de la plate-forme ne soient fusionnés dans l'arborescence principale du noyau. Créer efficacement une branche du noyau sur laquelle un certain nombre de fournisseurs différents s'appuient désormais.

—  Greg Kroah-Hartman , 2010

Aujourd'hui, Android utilise un Linux légèrement personnalisé où les modifications sont implémentées dans les pilotes de périphérique, de sorte que peu ou pas de modification du code du noyau du noyau est nécessaire. Les développeurs Android soumettent également des correctifs au Linux officiel qui peut enfin démarrer le système d'exploitation Android. Par exemple, un Nexus 7 peut démarrer et exécuter Linux principal.

Lors d'une présentation en 2001 au Computer History Museum , Linus Torvalds avait ceci à dire en réponse à une question sur les distributions de Linux utilisant précisément les mêmes sources de noyau ou non :

Ils ne le sont pas... eh bien, ils le sont, et ils ne le sont pas. Il n'y a pas de noyau unique. Chaque distribution a ses propres changements. Cela dure depuis à peu près le premier jour. Je ne sais pas si vous vous souvenez peut-être qu'Yggdrasil était connu pour avoir apporté des changements assez extrêmes au noyau et même aujourd'hui, tous les principaux fournisseurs ont leurs propres ajustements car ils ont une partie du marché qui les intéresse et très franchement, c'est ainsi que ça devrait être. Parce que si tout le monde s'attend à ce qu'une personne, moi, soit capable de suivre tout ce qui n'est pas le but de la GPL. Ce n'est pas l'intérêt d'avoir un système ouvert. Donc en fait, le fait qu'une distribution décide que quelque chose est si important pour elle qu'elle ajoutera des correctifs même si ce n'est pas dans le noyau standard, c'est vraiment un bon signe pour moi. C'est donc par exemple comment quelque chose comme ReiserFS a été ajouté. Et la raison pour laquelle ReiserFS est le premier système de fichiers de journalisation qui a été intégré dans le noyau standard n'est pas parce que j'aime Hans Reiser. C'est parce que SUSE a commencé à être livré avec ReiserFS comme noyau standard, ce qui m'a dit « ok ». Il s'agit en fait d'une utilisation en production. Les gens normaux font ça. Ils doivent savoir quelque chose que je ne sais pas. Donc, dans un sens très réel, ce que font beaucoup de maisons de distribution, elles font partie de ce « fabriquons notre propre succursale » et « apportons nos modifications à cela ». Et grâce à la GPL, je peux en prendre les meilleures portions.

—  Linus Torvalds , 2001

Conflits communautaires de développement

Il y a eu plusieurs conflits notables entre les développeurs du noyau Linux. Des exemples de tels conflits sont :

  • En juillet 2007, Con Kolivas a annoncé qu'il cesserait de développer pour le noyau Linux.
  • En juillet 2009, Alan Cox a quitté son rôle de mainteneur de la couche TTY après un désaccord avec Linus Torvalds .
  • En décembre 2010, il y a eu une discussion entre le mainteneur Linux SCSI James Bottomley et le mainteneur SCST Vladislav Bolkhovitin sur la pile cible SCSI qui devrait être incluse dans le noyau Linux. Cela a bouleversé certains utilisateurs de Linux.
  • En juin 2012, Torvalds a clairement indiqué qu'il n'était pas d'accord avec NVIDIA pour publier ses pilotes comme fermés.
  • En avril 2014, Torvalds a interdit à Kay Sievers de soumettre des correctifs au noyau Linux pour ne pas avoir traité les bogues qui ont provoqué une interaction négative de systemd avec le noyau.
  • En octobre 2014, Lennart Poettering a accusé Torvalds de tolérer le style de discussion brutal sur les listes de diffusion liées au noyau Linux et d'être un mauvais modèle.
  • En mars 2015, Christoph Hellwig a déposé une plainte contre VMware pour violation du droit d'auteur sur le noyau Linux. Linus Torvalds a clairement indiqué qu'il n'était pas d'accord avec cette initiative et d'autres similaires en qualifiant les avocats de maladie purulente.

Les principaux développeurs du noyau Linux sont conscients de l'importance d'éviter les conflits entre les développeurs. Pendant longtemps, il n'y avait pas de code de conduite pour les développeurs du noyau en raison de l'opposition de Linus Torvalds . Cependant, un code de conflit du noyau Linux a été introduit le 8 mars 2015. Il a été remplacé le 16 septembre 2018 par un nouveau code de conduite basé sur le Contributor Covenant . Cela a coïncidé avec des excuses publiques de Torvalds et une brève pause du développement du noyau. Le 30 novembre 2018, conformément au Code de conduite , Jarkko Sakkinen d'Intel a envoyé des correctifs remplaçant les instances de « fuck » apparaissant dans les commentaires du code source par des versions appropriées axées sur le mot « câlin ».

Base de code

En 2021, la version 5.11 du noyau Linux contenait environ 30,34 millions de lignes de code, environ 14% du code fait partie du "noyau" (répertoires arch, kernel et mm) tandis que 60% sont des pilotes.

Linux est une évolution, pas une conception intelligente !

—  Linus Torvalds , 2005

Coût estimé pour réaménager

Coûts de redéveloppement du noyau Linux

Le coût de redéveloppement de la version 2.6.0 du noyau Linux dans un environnement de développement propriétaire traditionnel a été estimé à 612 millions de dollars américains (467 millions d'euros, 394 millions de livres sterling) aux prix de 2004 en utilisant le modèle d'estimation de mois-personnes COCOMO . En 2006, une étude financée par l'Union européenne a estimé le coût de redéveloppement de la version 2.6.8 du noyau plus élevé, à 882 millions d'euros (1,14 milliard de dollars, 744 millions de livres sterling).

Ce sujet a été revisité en octobre 2008 par Amanda McPherson, Brian Proffitt et Ron Hale-Evans. En utilisant la méthodologie de David A. Wheeler, ils ont estimé que le redéveloppement du noyau 2.6.25 coûte maintenant 1,3 milliard de dollars (une partie d'un total de 10,8 milliards de dollars pour redévelopper Fedora 9). Encore une fois, Garcia-Garcia et Alonso de Magdaleno de l'Université d'Oviedo (Espagne) estiment que la valeur ajoutée annuellement au noyau était d'environ 100 millions d'euros entre 2005 et 2007 et 225 millions d'euros en 2008, cela coûterait également plus de 1 milliard d'euros (environ 1,4 milliard de dollars à partir de février 2010) à se développer dans l'Union européenne.

Au 7 mars 2011, en utilisant les LOC (lignes de code) d'un noyau Linux 2.6.x et les chiffres des salaires avec les calculs de David A. Wheeler, il en coûterait environ 3 milliards de dollars (environ 2,2 milliards d'euros) pour redévelopper le noyau Linux en tant que ça ne cesse de grossir. Un calcul mis à jour au 26 septembre 2018, utilisant 20 088 609 LOC (lignes de code) alors en vigueur pour le noyau Linux 4.14.14 et le salaire moyen actuel du programmeur américain de 75 506 $ montre qu'il en coûterait environ 14 725 449 000 dollars (11 191 341 000 £) pour réécrire le code existant.

Maintenance et accompagnement à long terme

Messages de démarrage d'un noyau Linux 2.6.25.17

La dernière version du noyau et les anciennes versions du noyau sont conservées séparément. La plupart des dernières versions du noyau ont été supervisées par Linus Torvalds. Les versions actuelles sont publiées par Greg Kroah-Hartman .

La communauté des développeurs du noyau Linux maintient un noyau stable en appliquant des correctifs pour les bogues logiciels qui ont été découverts lors du développement du noyau stable suivant. Par conséquent, www.kernel.org listera toujours deux noyaux stables. Le prochain noyau Linux stable est maintenant publié seulement 8 à 12 semaines plus tard. Par conséquent, les mainteneurs du noyau Linux ont désigné certaines versions de noyau stables comme à long terme , ces noyaux Linux de support à long terme sont mis à jour avec des corrections de bogues pendant deux ans ou plus. En novembre 2019, il y avait cinq noyaux Linux à long terme : 4.19.84, 4.14.154, 4.9.201, 4.4.201 et 3.16.76. La liste complète des versions se trouve dans l' historique des versions du noyau Linux .

Relation avec les distributions Linux

La plupart des utilisateurs Linux exécutent un noyau fourni par leur distribution Linux . Certaines distributions proposent les noyaux "vanilla" ou "stable". Cependant, plusieurs fournisseurs de distribution Linux (tels que Red Hat et Debian ) maintiennent un autre ensemble de branches du noyau Linux qui sont intégrées à leurs produits. Ceux-ci sont généralement mis à jour à un rythme plus lent par rapport à la branche "vanille", et ils incluent généralement tous les correctifs de la branche "stable" concernée, mais en même temps, ils peuvent également ajouter la prise en charge de pilotes ou de fonctionnalités qui n'avaient pas été publiés dans la version "vanille" à partir de laquelle le fournisseur de distribution a commencé à baser sa branche.

Les aspects légaux

Conditions de licence GPLv2

Initialement, Torvalds a publié Linux sous une licence qui interdisait toute utilisation commerciale. Cela a été modifié dans la version 0.12 par un passage à la licence publique générale GNU version 2 (GPLv2). Cette licence permet la distribution et la vente de versions éventuellement modifiées et non modifiées de Linux mais requiert que toutes ces copies soient diffusées sous la même licence et soient accompagnées - ou que, sur demande, un accès gratuit soit donné - au code source complet correspondant. Torvalds a décrit la licence Linux sous GPLv2 comme la « meilleure chose que j'aie jamais faite ».

Le noyau Linux est sous licence explicite uniquement sous la version 2 de la GPL, sans offrir au licencié la possibilité de choisir « toute version ultérieure », qui est une extension courante de la GPL. La branche git officielle de Torvalds contient une documentation qui explique le processus de développement du noyau aux personnes qui souhaitent travailler avec la communauté et contribuer au code ; il indique clairement que "[Toutes] contributions qui ne sont pas couvertes par une licence compatible [GPLv2] ne seront pas acceptées dans le noyau.".

Il y a eu un débat considérable sur la facilité avec laquelle la licence pourrait être modifiée pour utiliser les versions ultérieures de la GPL (y compris la version 3), et si ce changement est même souhaitable. Torvalds lui-même a spécifiquement indiqué lors de la sortie de la version 2.4.0 que son propre code n'est publié que sous la version 2. Cependant, les termes de la GPL stipulent que si aucune version n'est spécifiée, alors n'importe quelle version peut être utilisée, et Alan Cox a souligné que très peu d'autres contributeurs Linux avaient spécifié une version particulière de la GPL.

En septembre 2006, une enquête menée auprès de 29 programmeurs clés du noyau a indiqué que 28 préféraient la GPLv2 à la version actuelle de la GPLv3. Torvalds a commenté : « Je pense qu'un certain nombre d'étrangers… pensaient que je n'étais personnellement que l'étrange homme parce que je n'ai pas été si publiquement un grand fan de la GPLv3 ». Ce groupe de développeurs de noyaux de premier plan, dont Torvalds, Greg Kroah-Hartman et Andrew Morton , a commenté dans les médias de masse leurs objections à la GPLv3. Ils ont évoqué des clauses concernant les DRM / tivoisation , les brevets, les "restrictions supplémentaires" et ont mis en garde contre une balkanisation de "l'Univers Open Source" par la GPLv3. Linus Torvalds, qui a décidé de ne pas adopter la GPLv3 pour le noyau Linux, a réitéré ses critiques même des années plus tard.

Modules noyau chargeables

Il est débattu de savoir si certains modules de noyau chargeables (LKM) doivent être considérés comme des œuvres dérivées en vertu de la loi sur le droit d'auteur, et donc s'ils tombent ou non sous les termes de la GPL.

Conformément aux règles de licence, les LKM utilisant uniquement un sous-ensemble public des interfaces du noyau sont des œuvres non dérivées, ainsi Linux donne aux administrateurs système les mécanismes pour charger des objets binaires hors de l'arbre dans l'espace d'adressage du noyau.

Il existe des modules chargeables hors de l'arborescence qui font un usage légitime de la fonctionnalité du noyau dma_buf . Un code conforme à la GPL peut certainement l'utiliser. Cependant, un autre cas d'utilisation possible serait Nvidia Optimus qui associe un GPU rapide à un GPU intégré Intel, où le GPU Nvidia écrit dans le framebuffer Intel lorsqu'il est actif. Mais Nvidia ne peut pas utiliser cette infrastructure car elle nécessite de contourner une règle qui ne peut être utilisée que par des LKM également sous GPL. Alan Cox a répondu sur LKML , rejetant une demande d'un de leurs ingénieurs de supprimer cette application technique de l'API. Torvalds a clairement déclaré sur le LKML que "[je] prétends que les modules de noyau uniquement binaires SONT des dérivés "par défaut"".

D'un autre côté, Torvalds a également déclaré que "[une] zone grise en particulier est quelque chose comme un pilote qui a été écrit à l'origine pour un autre système d'exploitation (c'est-à-dire clairement pas un travail dérivé de Linux à l'origine). C'est une zone grise , et _c'est_ le domaine où je pense personnellement que certains modules peuvent être considérés comme des travaux non dérivés simplement parce qu'ils n'ont pas été conçus pour Linux et ne dépendent d'aucun comportement particulier de Linux". Les pilotes graphiques propriétaires , en particulier, sont fortement discutés.

Blobs binaires du micrologiciel

Le noyau officiel, c'est-à-dire la branche git de Linus dans le dépôt kernel.org, ne contient aucun type de code propriétaire ; Cependant, Linux peut rechercher dans les systèmes de fichiers pour localiser des micrologiciels propriétaires, des pilotes et d'autres modules exécutables (collectivement appelés « blobs binaires »), puis il peut les charger et les lier dans l'espace du noyau. Chaque fois que des modules propriétaires sont chargés dans Linux, le noyau se signale lui-même comme étant "souillé", et donc les rapports de bogues provenant de noyaux contaminés seront souvent ignorés par les développeurs.

Lorsque cela est nécessaire (par exemple, pour accéder aux périphériques de démarrage ou pour la vitesse), le firmware peut être intégré au noyau, cela signifie construire le firmware dans vmlinux ; cependant, ce n'est pas toujours une option viable pour les problèmes techniques ou juridiques (par exemple, il n'est pas permis d'utiliser un micrologiciel non compatible GPL).

Marque déposée

Linux est une marque déposée de Linus Torvalds aux États-Unis, dans l'Union européenne et dans certains autres pays. Une bataille juridique sur la marque a commencé en 1996, lorsque William Della Croce, un avocat qui n'a jamais été impliqué dans le développement de Linux, a commencé à demander des frais de licence pour l'utilisation du mot Linux . Après qu'il a été prouvé que le mot était d'usage courant bien avant la première utilisation revendiquée par Della Croce, la marque a été attribuée à Torvalds.

Voir également

Remarques

Les références

Lectures complémentaires

Liens externes