Newsgroup: it.comp.os.linux.iniziare
Titolo: [non mi sparate] interfaccia tra kernel e .config

hola.
non mi infamate subito, please!
ieri dopo mille tribolazioni sono riuscito a ricompilare un 2.6.8.1
(funzionante :) e mi sono chiesto:
"cristo, quanto e' complicato!"
prescindendo dal fatto che, secondo me, da profano, la suddivisione dei
menu e dei sotto menu non e' molto facile da comprendere per un non
esperto, ma cmq rizzati; non e' cosi' importante. chi non si cuole
avventurare nella ricompilazione, puo' usare quelli pacchettizzati dalle
varie distro.
Il mio dubbio era un altro: riuscire a capire quali sono i moduli che
servono e quelli inutili (ovviamente nel caso specifico).
faccio il mio esempio:
da poco ho reinstallato debian, con il net-installer di sarge e kernel
2.6.3; ora al momento del boot e dell'installazione, linux (avviato da cd)
ha fatto un check del mio sistema, si e' accorto che periferiche/device
usava e ha caricato i moduli necessari. Al primo boot funzionavano tutti i
vari devices, quindi ha fatto perfettamente il suo lavoro.
Ovviamente i kernel di default delle distro sono stra-modulari per
adattarsi a "tutte" le possibili soluzioni; ad un certo punto uno puo'
sentire il bisogno di farsi un kernel su misura e qui cominciano i casini
della scelta dei moduli.
Da profano quale sono interpreto cosi' il funzionamento del processo di
ricompilazione del kernel: una volta modificato un banalissimo "file di
testo" (.config) tramite l'interfaccia (o a mano se uno e' masochista),
"qualcosa"[chiamiamolo interprete],che sta dentro al tar.bz2 scaricato da
kernel.org
, legge il file di testo e compila il kernel del miglior sistema
operativo esistente... leggendo il .config, si nota che e' fatto cosi':
CONFIG_NOME_"OPZIONE"=Y/M o "is not set"
quindi l'interprete di cui sopra, legge questo file e in base a questo
compila il modulo corrispondente al "NOME OPZIONE" e lo include nel
kernel (Y) ovvero lo rende standalone(M) ovvero non lo considera affatto.
quindi l'interprete e' in grado di "collegare" il "nome opzione" (ad
esempio, snd_emu10k1) del .config al sorgente che deve compilare per
creare il modulo (il snd-emu10k1 appunto, per la soundblaster live).
Ora, ipotizzando di voler ricompilare un kernel partendo da un sistema
funzionante, perche' non esiste un qualche tool (con le stesse capacita'
di interpretazione dell'interprete di cui sopra-permettete la ripetizione)
che dato l'output di lsmod (quindi i moduli usati/caricati in quel momento
dal kernel funzionante) non compila una parte del .config ??
oppure qualche tool che dopo un'analisi del sistema (cosi' come fanno i
vari installer) compila un .config con attivati i moduli necessari a far
funzionare QUEL sistema?
Ovviamente sarebbe un .config da rifinire molto,pero' sarebbeun ottimo
inizio per il principiante che magari ha una scheda ati all in wonder e
non ha idea che la voce da attivare nel kernel e' la bt878...
La sto pensando nell'ottica di una (sempre maggiore) espansione di linuzx
sul desktop...
 c'e' qualche cosa che ignoro del funzionamento che
rende tutto cio' inutile/impossibile/pericoloso/ecc ?
cosa ne pensate?
-- 
Mr.Orange							       
antani _chiocciolina_ gmail _punto_ com		
orangeek dot homelinux dot org

 inizio per il principiante 
[...]
c'è il .config del kernel in uso.. 
	cp /path/kernel/old/.config /path/kernel/new/
	make menuconfig
a questo punto lavori solo "a togliere", per rendere il tutto piu' agile.
Tools.. non saprei (ci sono? servono? sono all'oscuro)
Ciao
-- 
--------------
s/ehila/yahoo 
--------------

 
e' vero, anche se aggiungo che non tutte le distro accludono il config del
kernel usato per l'installazione ad esempio.
e cmq si ripropone il problema: scegliere i moduli!
nel tuo caso, vorrebbe dire cosa togliere e cosa lasciare > quindi,
secondo me, siamo al solito problema.
no, sinceramente, mi chiedo se ci siano problemi tecnici... a me, da
assoluto profano, mi sembra un' "equazione" abbastanza semplice. se
l'interprete "pre compilazione" trasforma scelte nel .config in moduli,
dovrebbe essere possibile anche il contrario.
Inoltre, i sistemi utilizzati dai cd di installazione ( o dalle
live-distro) potrebbero farlo benissimo...
boh.


 cosa ne pensate?
Di solito, almeno finora su tutte le RedHat/Fedora e sulle Debian che ho
provato, la configurazione del kernel di default, quello installato dalla
distribuzione, e' in /boot/config-versione-del-kernel. 
In RedHat/Fedora, c'e' anche una directory nei sorgenti del kernel che si
chiama configs che contiene tutti i config di tutte le varianti dei kernel
forniti precompilati, tipo i386, i586, i686, i686-smp ecc.
Non uso il .config che si trova nei sorgenti perche' spesso mi sono
accorto che non corrisponde alla versione installata.
Una volta che hai il config giusto, puoi passare ad ottimizzare. Tanto per
darti una idea, di solito elimino subito PCMCIA support da un desktop,
come pure il supporto MTD (Memory Technology Device) che non ha nulla a
che fare con le "chiavette" USB. Tolgo il supporto per HAM-Radio,
Telephony, EISA, e cosi' via. Se non ho periferiche Bluetooth elimino pure
quello. Non tocco Networking e Filesystems, nel senso che tolgo solo cose
di cui sono assolutamente certo, tipo il supporto ReiserFS, XFS e JFS (che
non uso mai). Ma questo magari e' un passo successivo. 
C'e' una opzione del kernel che ti permette di fargli generare un .config
che riflette la sua configurazione, ma di solito nei kernel di default non
e' abilitata, anche perche' ti danno gia' la configurazione. 
-- 
Mario "Reliant" Pascucci
http://ilpettegolo.altervista.org/