Regole del forum
1) Citare sempre la versione di Slackware usata, la versione del Kernel e magari anche la versione della libreria coinvolta. Questi dati aiutano le persone che possono rispondere.
2) Per evitare confusione prego inserire in questo forum solo topic che riguardano appunto Gnu/Linux in genere, se l'argomento è specifico alla Slackware usate uno dei forum Slackware o Slackware64.
3) Leggere attentamente le risposte ricevute
4) Scrivere i messaggi con il colore di default, evitare altri colori.
5) Scrivere in Italiano o in Inglese, se possibile grammaticalmente corretto, evitate stili di scrittura poco chiari, quindi nessuna abbreviazione tipo telegramma o scrittura stile SMS o CHAT.
6) Appena registrati è consigliato presentarsi nel forum dedicato.
La non osservanza delle regole porta a provvedimenti di vari tipo da parte dello staff, in particolare la non osservanza della regola 5 porta alla cancellazione del post e alla segnalazione dell'utente. In caso di recidività l'utente rischia il ban temporaneo.
ho visto che in passato è già stato affrontato un argomento simile, ma per non riprendere un post troppo vecchio (il piu' recente è del 2012) ricomincio da capo
come da titolo del post ho di recente aggiornato il kernel e mi sono accorto che per quanto lo faccia in background inizia a metterci sempre piu' tempo.. da qui' ho pensato a come poter snellire la configurazione in modo da ridurre si il tempo di compilazione ma avere comunque un kernel funzionante.
mi è venuta in soccorso l'opzione
che pero' anche dai post che ho trovato qui prevede un intervento manuale perchè anche come spiegato alla sua introduzione scansiona i moduli attualmente caricati dal kernel e li riporta nel file di configurazione del kernel rimuovendo tutti gli altri.
percio' mi sto per cimentare in questa impresa con la seguente strategia
utilizzare il config generic distribuito con slackware
connettere i device esterni che tipicamente utilizzo (con particolare attenzione agli hard disk esterni)
lanciare make localmodconfig
con il solito make menuconfig attivare i filesystem che mi servono ed eventuali codepage a corredo
verificare che sia abilitata la virtualizzazione (non ricordo se quel modulo viene caricato anche senza usare qemu)
fatto questo c'e' qualcuno che compila il kernel in questo modo e ha qualche suggerimento?!?!
inoltre quando sara' che il kernel salta di versione (2.14.x -> 2.16.x) mi conviene fare un controllo manuale per vedere se i moduli che utilizzo hanno opzioni nuove!?!? oppure con make oldconfig !??! oppure meglio rieseguire paro paro la procedura che intendo eseguire?!
La "make localmodconfig" ha un "difetto", che difetto non è: lascia comunque attive tutte le voci che hanno "Y".
Quindi io andrei a manina e ritoccherei una per una le voci, tanto hanno una descrizione abbastanza esplicativa.
(Potresti stupirti di quanta roba sia inutile per desktop)
In più applicherei la patch BFS di Con Kolivas: applica uno scheduler decisamente migliore per uso desktop.
Quando aggiorni una release, "make oldconfig" è più che sufficiente per il 99.9% dei casi.
Blallo ha scritto:(Potresti stupirti di quanta roba sia inutile per desktop)
no, non mi stupisco..
per quanto riguarda le patch che mi hai suggerito, ho sempre compilato il vanilla, ma giusto l'altro giorno ho compilato 'vecchia' maniera il 2.16.3 con patch BFS e BFQ e devo ammettere che la differenza l'ho notata in quanto a responsività in generale!!
per quanto riguarda il discorso del difetto di cui mi parlavi.. volevo provare a partire da un config totalmente vuoto lanciando make allmodconfig che a quanto leggo mette i moduli laddove possibile.. poi da li' scremare quelli che utilizzo e aggiungere filesystem e virtualizzazione in seguito... che ne pensi?!?!
comunque mi sembra di capire che una volta trovata la mia configurazione.. automatizzata oppure no... me la devo conservare e passare da un kernel all'altro con molta cautela
Anche io uso make oldconfig su nuove release. Per le opzioni minimali, io la prima volta mi sono spulciato quasi tutto il "make menuconfig" e da lì procedo sempre con oldconfig.
E' puro esercizio (da fare solo per i PC di casa), anche perché alla fine avere tutti i moduli belli e compilati è sempre utile. Ma io mi diverto sempre quando poi all'avvio si pianta tutto .
Emanuele
Linux Registered User #454438 Se pensi di essere troppo piccolo per fare la differenza, prova a dormire con una zanzara -- Dalai Lama 20/04/2013 - Io volevo Rodotà
targzeta ha scritto:E' puro esercizio (da fare solo per i PC di casa),
sono d'accordo con te... ho fatto un po' di esperimenti e sono riuscito a compilare un kernel che è piu' grosso del generic , ma il numero dei moduli è effettivamente ridotto all'essenziale (chiaramente per la pennina wireless marca X modello Y non c'e' speranza).. mi sa che dovro' spulciare anche io opzione per opzione
l'unica cosa che non ho effettivamente provato è l'effettivo funzionamento del make oldconfig. provo a spiegare, in passato le poche volte che mi sono aggiornato il kernel procedevo un po' alla pat (credo)... ovvero lanciavo il make oldconfig e il piu' delle volte quando mi chiedeva se la nuova funzionalità X la volevo escludere/includere/modulo c'avevo il tasto fisso sulla M (compilare come modulo).
ma se riesco ad ottenere un kernel che abbia tutto cio' che serve per girare con l'hardware in mio possesso è davvero necessario lanciare il make oldconfig?!?! insomma avete mai provato a copiare il vostro config in una nuova release del kernel facendo partire direttamente la compilazione??!?!
miklos ha scritto:per quanto riguarda il discorso del difetto di cui mi parlavi.. volevo provare a partire da un config totalmente vuoto lanciando make allmodconfig che a quanto leggo mette i moduli laddove possibile.. poi da li' scremare quelli che utilizzo e aggiungere filesystem e virtualizzazione in seguito... che ne pensi?!?!
Ci ho provato, ma 99% non mi si avviava perché mancava questo o quello.
Quindi partirei dal generic senza ombra di dubbio.
bisogna considerare che una buona parte del supporto e' built in:file system usb driver sata driver ide driver schede di rete multimediale,un po' di tempo perso per compilare,e' ben speso se devi avere a che fare con hardware diverso.io parto sempre da un vecchio config,make oldconfig e aggiungi i nuovi moduli,e metre vai avanti ti ritrovi un config sempre valido.imho
erio ha scritto:un po' di tempo perso per compilare,e' ben speso se devi avere a che fare con hardware diverso
a questa evenienza ci avevo già pensato.. infatti ho provato, una volta buildato il kernel, ad aggiungere un singolo modulo e ho constatato che compila solo il delta.
pero' sicuramente per quanto riguarda device usb cerchero' di compilare il possibile (anche se tolti i device wireless non saprei davvero cosa includere).. pero' pensavo pure che su un portatile oltre alla scheda grafica e sensori non mi serviranno mai i moduli per hardware differente.. come diceva Blallo c'e' talmente tanta roba inutile che alla fine il tempo che si risparmia in compilazione è notevole.
se non ricordo male se torni dentro al kernel con menuconfig e scegli dei moduli questi compilano e si aggiungono agli altri con make modules_install, il build lo fa solo sulla differenza non su tutto, il config di slackware non prevede il supporto usb nativo e se usi il portatile i moduli per la crittografia e altre cose servono,multimedia compili solo il supporto usb c'e' sicuramente da lavorare parecchio per scremare....
Anche io in passato mi ero fatto la domanda se valesse la pena ricompilare il kernel solo con il minimo indispensabile e dopo taaante prove sono giunto alla conclusione che, salvo casi particolar, non ne vale assolutamente la pena.
Si, è vero, si compila in minor tempo, ma non è che tutti i giorni compilo il kernel. Normalmente rimango sulla release installata di base e seguo gli aggiornamenti incrementali. Ad esempio ora sono su un kernel 3.10.56 e appena ne avrò voglia compilerò il 3.10.57 ed approffitterò anche per (ri)provare la patch CK.
Ricompilando solo i moduli al momento necessari, mi è capitato che aggiungendo una periferica USB non venisse riconosciuta, oppure che Virtualbox (o lxc, o kvm) non funzionassero più perché avevo dimenticato qualcosa. O peggio, che una partizione criptate non riuscissi più a leggerla perché non avevo compilato i moduli necessari.
Con molta pazienza si può ottenre un config "perfetto", almeno per uso personale, ma bisogna perderci molto più tempo di quanto non se ne guadagni nella compilazione del kernel.
La soddisfazione personale è indubbia, e forse questo è l'unico motivo per ottimizzare la configurazione del kernel.
Test non ne ho fatti, ma credo di poter affermare che il guadagno in velocità o occupazione memoria tra un kernel "generic" ed un ad-hoc non sia tale da gridare al miracolo, soprattutto viste le prestazioni del pc moderni. Anche il risparmio di spazio disco è trascurabile.