Quel est le contenu de cette base de code monolithique?
Je comprends la prise en charge de l’architecture du processeur, la sécurité et la virtualisation, mais je n’imagine pas qu’elle compte plus de 600 000 lignes.
Quels sont les motifs historiques et actuels pour lesquels les pilotes sont inclus dans la base de code du noyau?
Ces 15 millions et plus de lignes incluent-ils chaque pilote pour chaque élément de matériel? Si tel est le cas, la question se pose alors: pourquoi les pilotes sont-ils incorporés dans le noyau et non des packages séparés, détectés automatiquement et installés à partir d'ID de matériel?
La taille de la base de code pose-t-elle un problème pour les périphériques à stockage limité ou à mémoire limitée?
Il semblerait que la taille du noyau des périphériques ARM soumis à des contraintes d’espace serait gonflée si tout cela était intégré. Y a-t-il beaucoup de lignes sélectionnées par le pré-processeur? Appelez-moi fou, mais je ne peux pas imaginer une machine nécessitant autant de logique pour exécuter ce que je comprends être le rôle d'un noyau.
Existe-t-il des preuves que sa taille sera un problème dans plus de 50 ans en raison de sa nature apparemment en croissance constante?
L'inclusion des pilotes signifie que le nombre de périphériques augmentera.
EDIT : Pour ceux qui pensent que c'est la nature des noyaux, après quelques recherches, j'ai réalisé que ce n'était pas toujours le cas. Il n'est pas nécessaire que le noyau soit aussi volumineux, car le micro - noyau Mach de Carnegie Mellon était répertorié à titre d'exemple 'habituellement sous 10 000 lignes de code'.
la source
make menuconfig
pour voir quelle quantité de code peut être activée / désactivée avant la construction.Réponses:
Les pilotes sont maintenus dans le noyau. Ainsi, lorsqu'un changement de noyau nécessite une modification globale (recherche ou remplacement) (ou une modification manuelle), il est effectué par la personne qui effectue le changement. La mise à jour de votre pilote par des personnes apportant des modifications à l'API constitue un très bel avantage, au lieu d'avoir à le faire vous-même lorsqu'elle ne compile pas sur un noyau plus récent.
L'alternative (ce qui est le cas pour les pilotes maintenus en dehors de l'arborescence), est que le correctif doit être resynchronisé par ses mainteneurs pour suivre toutes les modifications.
Une recherche rapide a permis de lancer un débat sur le développement de pilotes dans l’arbre ou en dehors de celui-ci .
La façon dont Linux est maintenu consiste principalement à tout conserver dans le référentiel principal. La construction de petits noyaux simplifiés est prise en charge par les options de configuration permettant de contrôler
#ifdef
s. Ainsi, vous pouvez absolument construire de minuscules noyaux dépouillés qui ne compilent qu'une infime partie du code dans l'ensemble du référentiel.L’utilisation intensive de Linux dans les systèmes embarqués a permis de mieux prendre en charge la suppression de données que ce que Linux avait eu des années auparavant, lorsque l’arbre source du noyau était plus petit. Un noyau 4.0 super-minimal est probablement plus petit qu'un noyau 2.4.0 super-minimal.
la source
Selon cloc exécuté sous 3.13, Linux représente environ 12 millions de lignes de code.
lsmod | wc
Sur mon ordinateur portable Debian, 158 modules ont été chargés au moment de l'exécution. Le chargement dynamique de modules est donc un moyen bien utilisé de prendre en charge le matériel.Le système de configuration robuste (par exemple
make menuconfig
) est utilisé pour sélectionner le code à compiler (et plus précisément, le code à ne pas compiler). Les systèmes intégrés définissent leur propre.config
fichier avec uniquement le support matériel qui leur tient à coeur (y compris le support matériel intégré au noyau ou sous forme de modules chargeables).la source
Pour ceux qui sont curieux, voici le détail du linecount pour le miroir GitHub:
drivers
contribue à beaucoup de linecount.la source
grep -Pir "\x66\x75\x63\x6b" /usr/src/linux/ | wc -l
./documentation
a plus de 500 000 lignes de code? ....quoi?Jusqu'à présent, les réponses semblent être "oui, il y a beaucoup de code" et personne ne s'attaque à la question avec la réponse la plus logique: 15M +? ET ALORS? Qu'est-ce que 15 millions de lignes de code source ont à voir avec le prix du poisson? Qu'est-ce qui rend cela si inimaginable?
Linux fait clairement beaucoup. Beaucoup plus que toute autre chose ... Mais certains de vos arguments montrent que vous ne respectez pas ce qui se passe lors de sa construction et de son utilisation.
Tout n'est pas compilé. Le système de construction du noyau vous permet de définir rapidement des configurations qui sélectionnent des ensembles de code source. Certaines sont expérimentales, certaines anciennes, d'autres inutiles pour tous les systèmes. Regardez
/boot/config-$(uname -r)
(sur Ubuntu)make menuconfig
et vous verrez combien est exclu.Et c'est une distribution de bureau à cible variable. La configuration pour un système intégré ne prendrait que ce dont elle a besoin.
Tout n'est pas intégré. Dans ma configuration, la plupart des fonctionnalités du noyau sont construites sous forme de modules:
Pour être clair, ils pourraient tous être intégrés ... Tout comme ils pourraient être imprimés et transformés en un sandwich en papier géant. Cela n'aurait aucun sens si vous ne réalisiez pas une construction personnalisée pour une tâche matérielle distincte (dans ce cas, vous auriez déjà limité le nombre de ces éléments).
Les modules sont chargés dynamiquement. Même lorsqu'un système dispose de milliers de modules, il vous permet de ne charger que ce dont vous avez besoin. Comparez les sorties de:
Presque rien n'est chargé.
Les micro-noyaux ne sont pas la même chose. Seulement 10 secondes en regardant l’image principale de la page Wikipedia que vous avez liée mettraient en évidence le fait qu’elles sont conçues de manière complètement différente.
Les pilotes Linux sont internalisés (généralement sous la forme de modules chargés dynamiquement), et non par l'utilisateur, et les systèmes de fichiers sont également internes. Pourquoi est-ce pire que d'utiliser des pilotes externes? Pourquoi le micro est-il meilleur pour l'informatique à usage général?
Les commentaires soulignent encore une fois que vous ne l'obtenez pas. Si vous souhaitez déployer Linux sur du matériel discret (par exemple, aérospatiale, une TiVo, une tablette, etc.), vous le configurez pour ne générer que les pilotes dont vous avez besoin . Vous pouvez faire la même chose sur votre bureau avec
make localmodconfig
. Vous vous retrouvez avec une petite construction de noyau à des fins sans aucune flexibilité.Pour les distributions comme Ubuntu, un seul paquet de noyau de 40 Mo est acceptable. Non, il est préférable de préférer le scénario d'archivage et de téléchargement massif qui consiste à conserver plus de 4000 modules flottants sous forme de packages. Il utilise moins d’espace disque pour eux, est plus facile à empaqueter au moment de la compilation, plus facile à stocker et convient mieux à leurs utilisateurs (qui disposent d’un système qui fonctionne simplement).
L'avenir ne semble pas être un problème non plus. Le rythme de la vitesse du processeur, la densité / coût des disques et les améliorations de la bande passante semblent beaucoup plus rapides que la croissance du noyau. Un paquet de noyau de 200 Mo dans 10 ans ne serait pas la fin si le monde.
Ce n'est pas non plus une rue à sens unique. Le code est expulsé s'il n'est pas maintenu.
la source
tinyconfig bubble graph svg (violon)
script shell pour créer le JSON à partir de la construction du noyau, à utiliser avec http://bl.ocks.org/mbostock/4063269
Edit : avéré
unifdef
avoir certaines limitations (-I
est ignoré et-include
non pris en charge, ce dernier est utilisé pour inclure l'en-tête de configuration généré) à ce stade, l'utilisationcat
ne change pas grand chose:script et procédure mis à jour.
En plus des pilotes, arch, etc., il y a beaucoup de code conditionnel compilé ou non en fonction de la configuration choisie, le code n'est pas nécessairement dans les modules chargés dynamiquement, mais construit dans le noyau.
Ainsi, les sources téléchargées de linux-4.1.6 , ont choisi le tinyconfig , il n’active pas les modules et honnêtement, je ne sais pas ce qu’il permet ni ce qu’un utilisateur peut en faire au moment de l’exécution, de toute façon, configure le noyau:
construit le noyau
le processus de construction du noyau laisse les fichiers cachés appelés
*.cmd
avec la ligne de commande servant également à construire des.o
fichiers, à traiter ces fichiers et à extraire la copie cible et les dépendancesscript.sh
ci-dessous et à l'utiliser avec find :cela crée une copie pour chaque dépendance de la cible
.o
nommée.o.c
code .c
en-têtes .h (désinfectés)
la source
Les compromis entre les noyaux monolithiques ont été débattus en public entre Tananbaum et Torvalds dès le début. Si vous n'avez pas besoin de passer dans l'espace utilisateur pour tout, l'interface du noyau peut être plus simple. Si le noyau est monolithique, il peut être plus optimisé (et plus compliqué!) En interne.
Nous avons eu des modules comme compromis depuis un bon moment. Et cela continue avec des choses comme DPDK (déplacer davantage de fonctionnalités réseau hors du noyau). Plus il y a de noyaux ajoutés, plus il est important d'éviter le verrouillage; ainsi, plus de choses se déplaceront dans l'espace utilisateur et le noyau se réduira.
Notez que les noyaux monolithiques ne sont pas la seule solution. Sur certaines architectures, la limite noyau / espace utilisateur n'est pas plus chère que tout autre appel de fonction, ce qui rend les micro-noyaux attrayants.
la source