Quali benefici potrei vedere compilando un kernel Linux da solo? C'è qualche efficienza che potresti creare personalizzandola sul tuo hardware?
Quali benefici potrei vedere compilando un kernel Linux da solo? C'è qualche efficienza che potresti creare personalizzandola sul tuo hardware?
Risposte:
Nella mia mente, l'unico vantaggio che ottieni dalla compilazione del tuo kernel Linux è:
Imparerai come compilare il tuo kernel Linux.
Non è qualcosa che si deve fare per una maggiore velocità / memoria / xxx qualunque cosa. È una cosa preziosa da fare se questo è lo stadio in cui ti senti nel tuo sviluppo. Se vuoi avere una comprensione più approfondita di cosa sia tutta questa faccenda "open source", su come e quali siano le diverse parti del kernel, allora dovresti provare. Se stai solo cercando di accelerare il tempo di avvio di 3 secondi, allora ... qual è il punto ... vai a comprare un SSD. Se sei curioso, se vuoi imparare, compilare il tuo kernel è un'ottima idea e probabilmente ne otterrai molto.
Detto questo, ci sono alcuni motivi specifici in cui sarebbe opportuno compilare il proprio kernel (come diverse persone hanno sottolineato nelle altre risposte). Generalmente questi derivano da un'esigenza specifica che hai per un risultato specifico, ad esempio:
Il problema sta nel pensare che ci sia qualche vantaggio intrinseco nella compilazione del proprio kernel quando tutto sta già funzionando come dovrebbe essere, e non penso che ci sia. Anche se puoi passare innumerevoli ore disabilitando cose che non ti servono e modificando le cose che sono modificabili, il fatto è che il kernel Linux è già abbastanza ben sintonizzato (dalla tua distribuzione) per la maggior parte delle situazioni dell'utente.
La maggior parte degli utenti non ha bisogno di compilare il proprio kernel, la loro distribuzione ha fatto questo lavoro per loro. Di solito le distribuzioni includeranno un set di patch per integrarsi con determinate parti del modo in cui funziona la distribuzione, backport dei driver di dispositivo e correzioni da versioni più recenti, ma inedite del kernel o funzionalità che stanno sperimentando con i loro utenti.
Quando compili il tuo kernel, hai un paio di opzioni, puoi compilare un kernel Linus Torvalds ufficiale, questo non includerà nessuna delle patch o personalizzazioni aggiunte dalla tua distribuzione (che può essere buona o cattiva) oppure puoi usa il tuo strumento di ricostruzione della distribuzione per creare il tuo kernel.
I motivi per cui potresti voler ricostruire il tuo kernel includono:
Molti sviluppatori lo usano per creare anche versioni personalizzate del kernel per sistemi embedded o settop box in cui hanno bisogno di driver di dispositivo speciali o vogliono rimuovere funzionalità di cui non hanno bisogno.
bisectper scoprire dove è stato introdotto un bug ...
La compilazione del kernel consente di includere solo le parti rilevanti per il proprio computer, il che lo rende più piccolo e potenzialmente più veloce, soprattutto al momento dell'avvio. I kernel generici devono includere il supporto per la maggior parte dell'hardware possibile; all'avvio rilevano quale hardware è collegato al tuo computer e carica i moduli appropriati, ma ci vuole tempo per fare tutto ciò e hanno bisogno di caricare moduli dinamici, piuttosto che avere il codice inserito direttamente nel kernel. Non c'è motivo di avere il tuo kernel in grado di supportare 400 CPU diverse quando ce n'è solo una nel tuo computer o di supportare mouse bluetooth se non ne hai uno, è tutto lo spazio sprecato che puoi liberare
Non posso credere che la risposta accettata qui inizi dicendo "Non è qualcosa che devi fare per più velocità / memoria / xxx".
Questo è totalmente falso. Costruisco abitualmente i miei kernel su ordinazione per rimuovere sia il codice non necessario, sia per includere il codice di miglioramento delle prestazioni principalmente legato all'hardware. Ad esempio, eseguo alcuni hardware più vecchi e posso ottenere alcuni miglioramenti delle prestazioni abilitando i driver del kernel raramente abilitati come il supporto del chipset HPT36x su alcuni Mobo più vecchi che hanno questo built-in.
Un altro esempio, BIG SMP in Slackware è l'impostazione predefinita e su un Dell 2800, ad esempio, consumerà una stampa di dimensioni considerevoli per eseguire cose come GFSD (non come un modulo del kernel) che, tra l'altro, consuma tick della CPU per qualcosa che I non ho bisogno. Allo stesso modo per NFSD e altri catch-all per compiacere tutte le mentalità, il che va bene se stai solo cercando di ottenere un Linux su una scatola e in esecuzione ma se ti interessa "speed / memory / xxx qualunque", allora queste cose contano e funzionano .
Tutte le mie scatole di produzione sono kernel personalizzati. Se sono su hardware comune come un hardware della serie Dell (2800, 2850, 2900, ecc ...), è semplice copiare il file .config del kernel in ogni box e compilare il kernel e installarlo.
Ecco alcune situazioni in cui la compilazione del proprio kernel ti gioverà:
Un kernel con caricamento del modulo disabilitato è più sicuro. Ciò richiederà di selezionare i moduli di cui sai di aver bisogno e di includerli come parte del kernel, invece di compilarli come moduli.
Disabilitare il supporto per / dev / kmem o paralizzarlo con l'opzione del compilatore appropriata è una buona cosa per la sicurezza. Penso che la maggior parte delle distro lo faccia per impostazione predefinita ora.
Preferisco non usare initrd quando possibile. La personalizzazione del kernel per l'hardware da cui si elimina elimina initrd.
A volte una versione successiva del kernel avrà le caratteristiche di cui hai bisogno, ma oggi è molto raro. Ricordo che quando ho iniziato a usare Debian per la prima volta, usava i kernel 2.4, ma avevo bisogno di un kernel 2.6 per il supporto udev.
La disabilitazione dei protocolli / opzioni di rete non necessari può accelerare le prestazioni TCP / IP.
Disabilitare le opzioni che non ti servono riduce l'ingombro di memoria del kernel, il che è importante in ambienti con poca RAM. Quando si utilizza un sistema RAM da 256 MB come router, questo aiuta.
Trovo che tutti i dispositivi "tty" in / dev siano fastidiosi nei sistemi in cui generalmente accedo solo tramite seriale o ssh.
La compilazione del tuo kernel ti consente di partecipare al processo di sviluppo del kernel, sia che si tratti di cose semplici come fornire gli ID dei dispositivi PCI / USB per un driver esistente che potrebbero far funzionare un dispositivo più nuovo per te, sia coinvolto profondamente nella mischia del core sviluppo del kernel.
Consente inoltre di testare i kernel di sviluppo sull'hardware e di fornire feedback in caso di regressioni. Questo può essere particolarmente utile per te e gli altri se hai un hardware insolito. Se aspetti un kernel distro, può richiedere del tempo prima che le correzioni dei rapporti sui problemi vengano filtrate in una nuova versione del kernel distro.
Personalmente mi piace anche compilare i miei kernel per includere il supporto solo per l'hardware che ho. Quando esegui i kernel di distro e guardi l'output di lsmod(8), vedi molti moduli caricati per l'hardware che non hai. Questo può inquinare l'elenco dei moduli, / proc, / sys e i tuoi log in modo tale che quando stai cercando qualcosa che può essere nascosto tra il rumore; Inoltre, non puoi essere sicuro al 100% che quei moduli non contribuiscano a un problema che stai tentando di diagnosticare.
Ho la seconda risposta di gabe. (Il mio commento è troppo lungo, quindi sto postando come risposta).
A meno che tu non abbia uno scopo altamente specializzato (ad esempio macchine incorporate, rigorosa creazione di profili di sicurezza), non vedo alcun vantaggio pratico nel compilare il tuo kernel se non quello di vedere come è fatto. Esaminando metodicamente le opzioni, vedere come interagiscono tra loro per costruire il sistema è un ottimo modo per capire come funziona il sistema. È sorprendente quello che scopri quando provi a rimuovere componenti che non sembrano avere alcuno scopo per le attività che stai cercando di svolgere.
Attenzione però: perché saltare nella tana del coniglio è senza dubbio esilarante, risucchia più notti e fine settimana di quanto pensassi possibile!
Al lavoro, usiamo i kernel arrotolati a mano per applicare patch out-of-tree come vserver e unionfs.
A casa, sto compilando kernel rotolati a mano per scoprire quale commit ha introdotto un bug che sto riscontrando. Una volta terminato, probabilmente mi atterrerò su un kernel a rotazione manuale fino a quando il bug non verrà corretto nella mia distribuzione (Debian), a quel punto ritornerei di nuovo ai loro kernel.
Questa discussione è antichissima e tuttavia è ancora valida oggi come lo era quando è stata posta la domanda!
La risposta è: compili il kernel linux di tua scelta secondo le tue necessità e requisiti.
Sono validi molti scenari:
Sei un ingegnere e hai bisogno che la tua build soddisfi i requisiti / requisiti di prestazioni e sicurezza del tuo sistema, ti ricompili per soddisfare e / o superare i criteri specificati.
Sei un utente normale e hai un vecchio sistema che vuoi continuare a lavorare il più a lungo possibile, ti ricompili per aggiungere / rimuovere componenti per mantenere il tuo vecchio sistema ottimizzato.
Sei un utente normale con l'ultimo hardware più veloce e ha memoria / RAM più che sufficiente. Non è necessario ricompilare, ma è ancora possibile se si è interessati a saperne di più sul proprio sistema.
Vuoi solo essere come un utente quotidiano di Microsoft e / o Mac, non ricompilare e semplicemente andare con gli aggiornamenti dalla tua distribuzione a monte.
Mantieni gli scenari in arrivo :-)
A differenza degli utenti Mac / Windows, ciò che Linux fornisce è la scelta. La scelta di semplificare o ottimizzare il sistema in base alle proprie esigenze.
Per la maggior parte degli usi, i kernel generici sono adatti praticamente a qualsiasi hardware. Inoltre, di solito contengono (ed) patch specifiche per la distribuzione, quindi la compilazione del proprio kernel può (potrebbe) causare problemi.
I reson per compilare il proprio kernel sono:
Se non usassi la distribuzione basata sul sorgente non compilerei affatto il kernel.
Un altro caso oltre ai molti citati qui per avere kernel compilati personalizzati è la creazione di ambienti di avvio di rete specializzati in cui il caricamento del modulo non è fattibile e si devono distribuire kernel completamente funzionanti a macchine specifiche per compiti specifici.
Sono sorpreso che nessuno abbia menzionato questo motivo per compilare un kernel personalizzato:
perché vuoi usare un compilatore C / c ++ diverso. GCC è abbastanza buono per compilare il kernel di Linux. Ma ci sono compilatori di gran lunga superiori là fuori! Le ottimizzazioni di GCC sono un po 'alla base del compilatore C / C ++ di Intel. E Intel fornisce le librerie di primitive sulle prestazioni e lo strumento vtune, entrambi indispensabili per la produzione di un kernel linux ad alte prestazioni. Puoi arrivare così lontano solo con GCC e G ++. Praticamente, qualunque cosa tu faccia, il compilatore limiterà il risultato. Quindi, utilizzo il compilatore Intel e le librerie delle prestazioni. È un po 'grande: 1,5 GB di download, ma questo mi dà un'idea di ciò che è contenuto in un buon compilatore.
Il compilatore C / C ++ di Intel è disponibile gratuitamente per uso non commerciale. Ma è più facile accedere alla pagina di download del compilatore Intel c ++ con licenza non commerciale che cercare nel sito Web di Intel. Di solito non uso GCC / G ++ per niente. E non devi essere un programmatore. Basta impostare il proprio ambiente e modificare due righe nel file make in modo che puntino al compilatore Intel.
Quindi puoi ottenere una certa velocità seria!
What are the pros and cons of compiling your own kernel?Contro = non facile, molte situazioni senza valore aggiunto. Pro = sicurezza, prestazioni, se sai cosa stai facendo, dispositivi NAS per esempio, usando Linux per far funzionare un pezzo di hardware e avere capacità di rete e grafica.