Quel est l'avantage de compiler votre propre noyau Linux?
Quel avantage pourrais-je voir en compilant moi-même un noyau Linux? Y a-t-il une certaine efficacité que vous pourriez créer en la personnalisant à votre matériel?
Dans mon esprit, le seul avantage que vous obtenez vraiment de compiler votre propre noyau Linux est:
Vous apprenez à compiler votre propre noyau Linux.
Ce n'est pas quelque chose dont vous avez besoin pour faire plus de vitesse/mémoire/xxx que ce soit. C'est une chose précieuse à faire si vous vous sentez à ce stade de votre développement. Si vous voulez avoir une meilleure compréhension de ce qu'est toute cette chose "open source", comment et quelles sont les différentes parties du noyau, alors vous devriez essayer. Si vous cherchez simplement à accélérer votre démarrage de 3 secondes, alors ... à quoi ça sert ... allez acheter un ssd. Si vous êtes curieux, si vous voulez apprendre, alors compiler votre propre noyau est une excellente idée et vous en tirerez probablement beaucoup.
Cela dit, il existe des raisons spécifiques pour lesquelles il serait approprié de compiler votre propre noyau (comme plusieurs personnes l'ont souligné dans les autres réponses). Généralement, ils découlent d'un besoin spécifique que vous avez pour un résultat spécifique, par exemple:
- J'ai besoin que le système démarre/s'exécute sur du matériel avec des ressources limitées
- Je dois tester un correctif et fournir des commentaires aux développeurs
- J'ai besoin de désactiver quelque chose qui cause un conflit
- J'ai besoin de développer le noyau linux
- Je dois activer la prise en charge de mon matériel non pris en charge
- J'ai besoin d'améliorer les performances de x parce que j'atteins les limites actuelles du système (et je sais ce que je fais)
Le problème réside dans le fait de penser qu'il y a un avantage intrinsèque à compiler votre propre noyau quand tout fonctionne déjà comme il se doit, et je ne pense pas qu'il y en ait. Bien que vous puissiez passer d'innombrables heures à désactiver les choses dont vous n'avez pas besoin et à peaufiner les choses qui sont modifiables, le fait est que le noyau linux est déjà assez bien réglé (par votre distribution) pour la plupart situations utilisateur.
La plupart des utilisateurs n'ont pas besoin de compiler leur propre noyau, leur distribution a fait ce travail pour eux. Habituellement, les distributions comprendront un ensemble de correctifs à intégrer à certaines parties du fonctionnement de la distribution, des rétroportages de pilotes de périphériques et des correctifs à partir de versions plus récentes mais non publiées du noyau ou des fonctionnalités dont ils sont les pionniers avec leurs utilisateurs.
Lorsque vous compilez votre propre noyau, vous avez quelques options, vous pouvez compiler un noyau Linus Torvalds officiel, cela n'inclura aucun des correctifs ou personnalisations qui ont été ajoutés par votre distribution (qui peuvent être bons ou mauvais) ou vous pouvez utilisez votre outil de reconstruction de distribution pour construire votre propre noyau.
Les raisons pour lesquelles vous voudrez peut-être reconstruire votre noyau sont les suivantes:
- Corriger des bogues ou ajouter une fonctionnalité spécifique à un système de production, où vous ne pouvez pas vraiment risquer de mettre à niveau le noyau entier pour un ou deux correctifs.
- Pour essayer un pilote de périphérique particulier ou une nouvelle fonctionnalité
- Pour étendre le noyau, travaillez dessus
- tester certains des modules ou fonctionnalités "Alpha".
De nombreux développeurs l'utilisent pour créer également des versions personnalisées du noyau pour les systèmes embarqués ou les décodeurs où ils ont besoin de pilotes de périphériques spéciaux, ou ils souhaitent supprimer les fonctionnalités dont ils n'ont pas besoin.
La compilation du noyau vous-même vous permet d'inclure uniquement les parties pertinentes pour votre ordinateur, ce qui le rend plus petit et potentiellement plus rapide, en particulier au démarrage. Les noyaux génériques doivent inclure la prise en charge d'autant de matériel que possible; au démarrage, ils détectent le matériel connecté à votre ordinateur et chargent les modules appropriés, mais cela prend du temps et ils doivent charger les modules dynamiques, plutôt que de faire cuire le code directement dans le noyau. Il n'y a aucune raison pour que votre noyau prenne en charge 400 CPU différents lorsqu'il n'y en a qu'un dans votre ordinateur, ou pour prendre en charge les souris Bluetooth si vous n'en avez pas, c'est tout l'espace gaspillé que vous pouvez libérer
Je ne peux pas croire que la réponse acceptée ici commence par dire "Ce n'est pas quelque chose que vous devez faire pour plus de vitesse/mémoire/xxx."
C'est totalement faux. Je conçois régulièrement mes noyaux pour supprimer à la fois le code inutile et inclure le code d'amélioration des performances principalement lié au matériel. Par exemple, j'exécute un matériel plus ancien et je peux obtenir des gains de performances en activant des pilotes de noyau rarement activés tels que la prise en charge du chipset HPT36x sur certains MoBos plus anciens dotés de cette fonctionnalité intégrée.
Un autre exemple, BIG SMP sous Slackware est la valeur par défaut et sur un Dell 2800, par exemple, consommera une empreinte de pas importante pour exécuter des choses comme GFSD (pas en tant que module de noyau) qui, soit dit en passant, consomme également des ticks de CPU pour quelque chose que je pas besoin. De même pour NFSD et autres fourre-tout pour plaire à toutes les mentalités, ce qui est bien si vous essayez simplement d'obtenir un Linux sur une boîte et de le faire fonctionner mais si vous vous souciez de "vitesse/mémoire/xxx quoi que ce soit", alors ces choses importent et fonctionnent .
Toutes mes boîtes de production sont des noyaux personnalisés. Si je suis sur un matériel courant tel qu'un matériel de la série Dell (2800, 2850, 2900, etc ...), il suffit de copier le fichier .config du noyau dans chaque boîte et de compiler le noyau et de l'installer.
Voici quelques situations où la compilation de votre propre noyau vous sera bénéfique:
Un noyau avec chargement de module désactivé est plus sécurisé. Cela vous obligera à sélectionner les modules dont vous savez que vous avez besoin et à les inclure dans le noyau, au lieu de les compiler en tant que modules.
Désactiver la prise en charge de/dev/kmem, ou la paralyser avec l'option de compilation appropriée est une bonne chose pour la sécurité. Je pense que la plupart des distributions font cela par défaut maintenant.
Je préfère ne pas utiliser d'initrd lorsque cela est possible. La personnalisation de votre noyau en fonction du matériel à partir duquel il démarre élimine l'initrd.
Parfois, une version ultérieure du noyau aura les fonctionnalités dont vous avez besoin, mais c'est très rare aujourd'hui. Je me souviens quand j'ai commencé à utiliser Debian, il utilisait des noyaux 2.4, mais j'avais besoin d'un noyau 2.6 pour le support udev.
La désactivation des protocoles/options réseau dont vous n'avez pas besoin peut accélérer vos performances TCP/IP.
La désactivation des options dont vous n'avez pas besoin réduit l'empreinte mémoire du noyau, ce qui est important dans les environnements à faible RAM. Lorsque vous utilisez un système de 256 Mo RAM comme un routeur, cela aide.
Je trouve tous les périphériques "tty" dans/dev ennuyeux sur les systèmes où je ne me connecte généralement que via série ou ssh.
La compilation de votre propre noyau vous permet de participer au processus de développement du noyau, qu'il s'agisse de choses simples telles que la fourniture d'ID de périphérique PCI/USB pour un pilote existant qui peuvent faire fonctionner un périphérique plus récent pour vous, pour vous impliquer profondément dans l'effilochage du noyau développement du noyau.
Il vous permet également de tester les noyaux de développement sur votre matériel et de fournir des commentaires si vous remarquez des régressions. Cela peut être particulièrement utile pour vous et les autres si vous avez un matériel peu courant. Si vous attendez un noyau de distribution, cela peut prendre un certain temps avant que les correctifs de vos rapports de problèmes soient filtrés dans une nouvelle version du noyau de distribution.
Personnellement, j'aime aussi compiler mes propres noyaux pour inclure la prise en charge uniquement du matériel que j'ai. Lorsque vous exécutez des noyaux de distribution et regardez la sortie de lsmod(8), vous voyez beaucoup de modules chargés pour le matériel que vous n'avez pas. Cela peut polluer la liste des modules,/proc,/sys et vos journaux de telle sorte que lorsque vous recherchez quelque chose, il peut se cacher parmi le bruit; Vous ne pouvez pas non plus être sûr à 100% que ces modules ne contribuent pas à un problème que vous essayez de diagnostiquer.
J'appuie la réponse de gabe. (mon commentaire est trop long donc je poste comme réponse).
À moins que vous ayez un objectif hautement spécialisé (par exemple, des machines embarquées, un profilage de sécurité strict), je ne vois aucun avantage pratique à compiler votre propre noyau autre que de voir comment cela se fait. En examinant méthodiquement les options, voir comment elles interagissent les unes avec les autres pour construire le système est un excellent moyen de comprendre comment fonctionne votre système. C'est incroyable ce que vous découvrez lorsque vous essayez de supprimer des composants qui ne semblent pas avoir de but pour les tâches que vous essayez d'accomplir.
Soyez averti cependant - pourquoi sauter dans le terrier du lapin est sans aucun doute exaltant, il aspirera plus de nuits et de week-ends que vous ne le pensiez possible!
Au travail, nous utilisons des noyaux roulés à la main afin d'appliquer des correctifs hors arborescence tels que vserver et unionfs.
À la maison, je compile des noyaux roulés à la main afin de trouver quel commit a introduit un bug que je rencontre. Une fois que j'aurai terminé cela, je m'en tiendrai probablement à un noyau roulé à la main jusqu'à ce que le bogue soit corrigé dans ma distribution (Debian), auquel cas je reviendrais à nouveau sur leurs noyaux.
Ce fil est vieux et pourtant il est toujours valable aujourd'hui comme il l'était lorsque la question a été posée!
La réponse est: vous compilez le noyau linux de votre choix selon vos besoins et exigences.
De nombreux scénarios sont valides:
Vous êtes ingénieur et avez besoin que votre build réponde aux exigences/exigences de performance et de sécurité de votre système, vous recompilez pour répondre et/ou dépasser les critères spécifiés.
Vous êtes un utilisateur normal et avez un ancien système que vous souhaitez continuer à utiliser aussi longtemps que vous le pouvez, vous recompilez pour ajouter/supprimer des composants afin de garder votre ancien système optimisé.
Vous êtes un utilisateur normal avec le dernier matériel le plus rapide et il a plus qu'assez de mémoire/RAM. Pas besoin de recompiler mais vous pouvez toujours le faire si vous souhaitez en savoir un peu plus sur votre système.
Vous voulez juste être comme un utilisateur quotidien de Microsoft et/ou Mac, ne recompilez pas et allez simplement avec les mises à jour de votre distribution en amont.
Gardez les scénarios à venir :-)
Contrairement aux utilisateurs de Mac/Windows, ce que Linux offre, c'est le choix. Le choix de simplifier ou d'optimiser le système selon vos besoins.
Un autre cas en plus des nombreux mentionnés ici pour avoir des noyaux compilés personnalisés est la mise en place d'environnements de démarrage réseau spécialisés où le chargement de module n'est pas possible et vous devez distribuer des noyaux pleinement opérationnels à des machines spécifiques pour des tâches spécifiques.
Je suis surpris que personne n'ait mentionné cette raison de compiler un noyau personnalisé:
car vous souhaitez utiliser un autre compilateur C/c ++. GCC est assez bon pour compiler le noyau linux. Mais il existe des compilateurs largement supérieurs! Les optimisations de GCC sont un peu derrière le compilateur C/C++ d'Intel. Et Intel fournit les bibliothèques de primitives de performances et l'outil vtune, tous deux indispensables pour produire un noyau Linux hautes performances. Vous ne pouvez aller jusqu'ici qu'avec GCC et G ++. Peu importe ce que vous faites, le résultat sera limité par le compilateur. Donc, j'utilise le compilateur Intel et les bibliothèques de performances C'est un peu gros - téléchargement de 1,5 Go, mais cela donne une idée de tout ce qui est contenu dans un bon compilateur.
Le compilateur C/C++ d'Intel est disponible gratuitement pour une utilisation non commerciale. Mais il est plus facile de rechercher sur la page de téléchargement du compilateur Intel c ++ une licence non commerciale que de rechercher sur le site Web d'Intel. Je n'utilise habituellement GCC/G ++ pour rien. Et vous n'avez pas besoin d'être programmeur. Vous venez de définir votre environnement et de modifier deux lignes dans le fichier make pour pointer vers le compilateur d'Intel.
Ensuite, vous pouvez obtenir une vitesse sérieuse!
Pour la plupart des utilisations, les noyaux génériques conviennent à pratiquement n'importe quel matériel. De plus, ils contiennent généralement des correctifs spécifiques à la distribution (ed), donc la compilation de votre propre noyau peut (pourrait) causer des problèmes.
Le réson pour compiler votre propre noyau est:
- Vous utilisez une distribution basée sur la source donc il n'y a pas de noyau "générique"
- Vous êtes développeur de noyau et vous développez le noyau
- Vous devez personnaliser le noyau par exemple pour un périphérique embarqué avec un disque dur très limité
- Certains pilotes ne sont pas compilés (cas très rare)
- Vous voulez patcher le noyau ET vous savez ce que vous faites
- Vous voulez apprendre à compiler le noyau
Si je n'utilisais pas la distribution basée sur la source, je ne compilerais pas du tout le noyau.