kernel

gallows · Messaggio da **gallows** » gio 10 feb 2005, 19:33

monolitico o modulare?
 quali sono le vostre idee a riguardo?
 in quali casi conviene sceglierne uno rispetto all´altro?
 cosa conviene inserire staticamente e cosa no?
 
 se avete qualche link che ne parla non esitate a postarlo

j0ker · Messaggio da **j0ker** » gio 10 feb 2005, 19:40

Behh dipende dalle tue esigenze e dalla configurazione hardware del tuo pc...Di sicuro molte cose le devi inserire staticamente nel tuo kernel...comunque c´era una guida carina (non molto approfondita)ma molto utile <A HREF="http://www.html.it" TARGET="_blank">qui</A> dacci un´occhiata :-]

j0ker · Messaggio da **j0ker** » gio 10 feb 2005, 19:41

p.s.: Prima di passare alla ricompilazione del kernel creati i dischetti di avvio oppure mantieni la vecchia immagine del kernel cosi nel caso hai problemi puoi sempre ripristinare Ciao

gallows · Messaggio da **gallows** » gio 10 feb 2005, 21:26

non voglio consigli specifici su come ricompilarmi il kernel...
 volevo sapere i vostri pareri e le vostre esperienze

kernel: parliamone
 :))))

rob · Messaggio da **rob** » gio 10 feb 2005, 23:15

ok, discussione accettata

statico: supporti a fs, driver della mobo (comprendendo pci, usb, parallela ecc), driver dei drive (lettori cd...) e tutte quelle altre cose che già sono statiche di default
 
 modulare: ovviamente il resto
 
 moduli esclusi: quei driver appartenenti ad hw che mai avrò sul pc... e se ci dovesse capitare ricompilo xchè me lo sono meritato :-] :-] :-]
 
 ciao, rob

meritil · Messaggio da **meritil** » ven 11 feb 2005, 14:11

sottoscrivo l´ipotesi di rob
 
 statico solo lo stretto necessario..
 
 anche perchè non tutti sanno che:
 utilizzando un modulo si è in grado di passare ad esso tramite la clausola ´options´ in modprobe.conf dei parametri ad esso, per esempio ultimamente mi è servito di passare a usbcore il parametro OLD_SCHEME_FIRST=1
 se avessi compilato usbcore come statico non avrei avuto questa possibilità, anche se sono certo che si possa ottenere la stessa cosa utilizzando gli append in lilo.conf ma ad oggi non ho trovato nessuna referenza nei sui libri ne su internet sul come fare e sulla sintassi corretta.
 
 Ciao :-]

Messaggio da **useless** » ven 11 feb 2005, 14:56

è una cosa che mi chiedo anch´io quella di come passare parametri ai moduli compilati staticamente. a me serviva x ip_nat_irc. probabilmente si può fare qualcosa tramite /proc, /sys e/o sysctl, xò effettivamente non ho mai capito come

.

meritil · Messaggio da **meritil** » ven 11 feb 2005, 15:45

uè useless se trovi qualcosa, ricordati degl´amici :-] :-] :-]
 
 Io sto puntando agl´append di lilo, nel senso:
 Se un modulo diventa parte del kernel allora i parametri vanno passati al kernel no? tipo ide0=noprobe per esempio... o hdc=ide-scsi ... bah mai trovato nulla a riguardo però sigh!
 
 Ciao

fAu · Messaggio da **fAu** » ven 11 feb 2005, 15:54

nel mio piccolo io ho scelto monolitico sul server (l´hardware e´ quello e se dovro´ fare degli upgrade hardware dovrei comunque riavviarlo) e modulare sul laptop (a cui tutti i giorni puo´ capitare di attaccarci qualcosa).

NaiC · Messaggio da **NaiC** » ven 11 feb 2005, 16:23

Eccoci qua...
 Parliamo di teoria pura e di pratica grande.
 Vediamo, io sono per i kernel monolitici principalmente. In condizioni particolari mi sta bene anche il modulare a metà... quando si parla per esempio di macchine con una grande facilità di cambiamenti fisici come portatili o palm-pilot (si anche il mio palmare della Compaq ha la slackware ricompilata da me... e Apache e Postgre..).
 Per quanto riguarda l´essenza propria della scelta tra monolitico o modulare io farei una riflessione di tipo diverso.
 Pensiamo al pc di casa, una connessione in dial-up (anche l´adsl che viene attivata e disattivata lo è) e tante periferiche fiche come lo scanner, la stampantina, la quickcam, il joystick per giocare a Quake, la supermega scheda audio per far arrabbiare i vicini...
 Situazione poco critica... sono solo io che utilizzo il pc.. al massimo ci sono una decina di utenti che io conosco benone, al massimo, ma proprio se voglio strafare, creo un account per l´amico che si logga e ci parliamo tramite ytalk... non c´è grossa richiesta di protezione ne dall´esterno verso l´interno, ne dall´interno verso l´esterno... al massimo devo stare attento a non fare qualche cretinata io...
 Quindi, visto che oramai i sistemi casalinghi hanno prestazioni hardware molto elevate, crepi l´avarizia e mettiamo moduli su moduli, non tenendo presente che se devo leggere da disco un file grosso 20 kb impiegherò per i famosissimi tempi di accesso, per i famosissimi passaggi delle istruzioni e dei dati nei registri, e altre boiate che in questo ambito non ce ne frega nulla, impiegherò sempre come dicevo MENO tempo che leggere 2 file da 10 kb l´uno. Ancora peggio se sono 4 file da 5 kb l´uno... e così di fila...
 Stronzate? Non credo proprio... basta andare a vedere per bene i principi su cui si basano alcuni hardware e le conseguenze riusciamo a tirarle da soli.
 Se però dobbiamo pensare ad una macchina che faccia da server di rete e renda disponibili alcuni servizi che per un verso o per l´altro sono "indispenzabili"... bhè qui viene il bello.
 Solo ed esclusivamente kernel monolitici ed essenziali, nessuna possibilità di mettere moduli (non ritrovo il link ma c´è un articolo bellissimo di un certo Mitnick, sconosciutissimo signore, che spiega come si può giocare con i moduli di un kernel, sostituirli direttamente in memoria, camuffarli, inserire codice particolare all´interno... non che non si possa fare con un kernel monolitico... ma ne passa di acqua sotto i ponti tra il sostituire un modulo on-fly che è già mappato in memoria, e l´intero kernel... non so se mi spiego).
 Altro problemone.
 Non sempre i moduli sono fissi in memoria... la cosa bella è che quando un modulo non mi serve più lo scarico dalla memoria e sono felice...
 Ma se parliamo di sistemi con servizi in real-time, (e fidatevi ce ne sono più di quanti voi possiate immaginare), posso permettermi di aspettare (si parla sempre di tempi strettissimi ma pur sempre di tempi...) che si legga il modulo adatto, lo si carichi in memoria, lo si esegua ecc.. ecc???
 Pensateci... fatevi domande e datevi delle risposte...

))
 Ciao Ciao

rob · Messaggio da **rob** » ven 11 feb 2005, 17:09

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>Quote:<HR></TD></TR><TR><TD><BLOCKQUOTE> certo Mitnick, sconosciutissimo signore </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE>
 se è kevin... beh, nn è proprio tanto sconosciuto...

rob

meritil · Messaggio da **meritil** » ven 11 feb 2005, 19:23

Bè se la vogliamo mettere sul complicato allora c´è da dire che:
 1) la tendenza dei sistemi operativi è quella del microkernel, cioè un insieme di moduli nessuno dei quali può definirsi il nucleo, che insieme formano l´intero kernel.. Quindi l´opposto del monolitico..
 Il vantaggio enorme che se ne trae, non solo per i microkernel, ma anche di una scelta modulare, è quello che un modulo può essere gestito in multithreading, inutile menzionarvi i vantaggi del multithreading :-]
 2) La filosofia monolitica e centralizzata fallisce in ogni disciplina..
 3) Un modulo quando viene caricato, difficilmente viene fatto sloggiare dalla memoria, di solito succede solo in condizioni estreme.. ricordo inoltre che un modulo una volta caricato in termini di velocità non ha nesuna differenza con un filaccione di codice kernel..
 4) La scelta modulare consente di cambiare modulo senza cambiare kernel, pensate se il codice dei driver nvidia fosse embedded nel kernel.. ad ogni nuova release bisognerebbe ricompilare.. molti driver embedded nel kernel possono essere sostituiti senza ricompilare, per esempio sk98lin è un driver per schede di rete gigabit, se scaricate i sorgenti dal sito sysconnect quando compilate questi sorgenti vanno a ricreare e a sostituire tale modulo (sk98lin.o) se avete inserito come statico questa parte di codice allora vi tocca non solo ricompilare ma patchare il kernel prima di farlo..
 
 Ciao
 :-]

mangus · Messaggio da **mangus** » ven 11 feb 2005, 19:36

<TABLE BORDER=0 ALIGN=CENTER WIDTH=85%><TR><TD>Quote:<HR></TD></TR><TR><TD><BLOCKQUOTE>
 
 
 Io sto puntando agl´append di lilo, nel senso:
 Se un modulo diventa parte del kernel allora i parametri vanno passati al kernel no? tipo ide0=noprobe per esempio... o hdc=ide-scsi ... bah mai trovato nulla a riguardo però sigh!
 
 
 </BLOCKQUOTE></TD></TR><TR><TD><HR></TD></TR></TABLE>
 
 file:/usr/src/linux/Documentation/kernel-parameters.txt
 
 HTH

meritil · Messaggio da **meritil** » sab 12 feb 2005, 13:12

Si la guida l´avevo vista ma secondo essa:
 
 options usbcore OLD_SCHEME_FISRT=1
 
 andrebbe tradotta in:
 
 usbcore.OLD_SCHEME_FIRST=1
 
 Il problema è che non ha dato nessun effetto questo append.. forse è un problema di usbcore o altro(forse sbaglio sintassi), e magari su altri moduli inseriti staticametne funziona(ho provato solo con usbcore), non so.. ho preferito (sono stato costretto) a ricompilare mettendo usbcore come modulo..
 Ci riproverò cmqe, non mollo facilmente :-]
 
 Grazie Meritil

lckw · Messaggio da **lckw** » dom 13 feb 2005, 19:22

Ciao Meritil! Io ho i moduli Usb caricati nel kernel monolitico,e avendo la penna Usb che dava un errore (device descriptor read/64, error -71) quando montata a caldo,ho usato la seguente soluzione:
 bash-3.00# echo Y > /sys/module/usbcore/parameters/old_scheme_first
 
 In seguito ho inserito tale stringa nel file rc.local in modo che ad ogni riavvio la penna usb usasse il "vecchio schema".
 
 ---cosa è il vecchio schema?---
 Il vecchio schema non è altro che il modo in cui il kernel legge le informazioni presenti sul descrittore del dispositivo.
 All´inserimento della penna Usb il kernel assegna al dispositivo un indirizzo,poi invia ad esso un pacchetto di 8 byte
 per richiedere la lettura del descrittore del dispositivo,successsivamente legge i 18 byte di tale descrittore.
 
 ---cosa è il nuovo schema?---
 il nuovo schema consiste nell´inviare una richiesta di lettura tramite un pacchetto di 64 byte, in quanto ,a quanto ho capito ,
 al momento dell´inserimento della penna USB, linux identifica subito la sua velocità,e quindi le dimensioni massime dei pacchetti
 normalmente trasmessi da essa.però il motivo per cui questo sistema non funzioni sempre su linux non mi è noto.
 
 p.s.: sono interessato a conoscere meglio i "due schemi",quindi sarei felice che qualcuno ampliasse il discorso da me iniziato!
 
 ciao!!