Compilare il Kernel

[Emalele1688]

Scusate: Mi viene spontanea una domanda ...
Tempo fa ho compilato il Kernel senza includere il modulo OSS (Open Sound System), che credevo non fosse di vitale importanza;
Invece oggi mi sono accorto che ho un'applicazione che ne fa uso, quindi devo integrarlo ...
A prescindere dal fatto che tanto il Kernel lo devo ricompilare con nuove configurazioni, ma se si volesse includere un modulo non esiste alternativa alla ricompilazione?

[Gimli[2BV!2B]]

Riguardo all'OSS, immagino tu ti stia riferendo agli strati di compatibilità contenuti nei driver ALSA, non al vecchio OSS deprecato.

Se hai necessità di aggiungere un opzione e non un modulo, non conosco altro modo che rilanciare la compilazione principale.
Se i sorgenti non sono stati puliti (make clean o mrproper) e non si scatena una modifica che tocca tutti i sorgenti, si dovrà attendere la sola compilazione dei moduli (integrati o no) coinvolti.
Idem se si integra un modulo o si desidera rimuoverne l'integrazione.

Se si aggiunge un modulo, lasciandolo esterno al kernel, ci si può limitare ad un make modules && make modules_install
Solitamente si avrà la compilazione dei soli nuovi moduli (sempre se non si è fatto un clean), reinstallandoli poi tutti quanti.

Quindi consiglierei semplicemente di evitare di pulire i sorgenti (salvo in caso di limiti di spazio) o si può inserire la citata ccache, ma non conosco altre possibili scorciatoie.

[Emalele1688]

Riguardo OSS, ovviamente, mi riferivo solo alla compatibilità delle applicazioni OSS con ALSA. Credo che molte applicazioni multi piattaforma richiedono tale interfaccia ...
Dunque tanto per sapere il modulo in questione, SE NON ERRO, è snd-seq-oss.ko; Giusto?

Dunque sarebbe (teoricamente) bastato:
make modules snd-seq-oss
make modules_install snd-seq-oss
Giusto ?

Se invece ho bisogno di non caricare un modulo precedentemente integrato all'avvio, basta aggiungerlo alla blacklist?
/etc/modprobe.d/blacklist.conf
Per esempio posso togliere l'integrazione del modulo "neuveau" inserendo la riga
"blacklist nouveau"
sul file /etc/modprobe.d/blacklist.conf ??

[darkbasic]

A dire il vero è possibile compilare solo il modulo incriminato. Non ci ho mai provato, ma temo che sia necessario fare qualche modifica al makefile.

[WarDuck]

Originariamente inviato da darkbasic

Il problema di fedora è che è troppo bleeding edge, va bene giusto per testare nuove tecnologie per red hat enterprise.

Mi sa che non conosci Arch .

Tra l'altro molto più stabile di altre distro "a lunga durata".

[Emalele1688]

Arch la sto povando ora
L'ho installata su un'altra partizione, molto complessa ma anche molto interessante.

Ma come si integrano nel kernel i moduli compilati ma non integrati?
Basta dare il comando modprobe nome_modulo?
Le blacklist che sono?

[darkbasic]

Originariamente inviato da WarDuck

Mi sa che non conosci Arch

Fosse per me non sarebbe un problema (la mia gentoo è bleeding edge da fare schifo) ma non me la sentierei di consigliare distro simili a chi non è avvezzo.

[Emalele1688]

Ma secondo voi può essere che sotto Arch linux la compilazione di un file cpp sia di gran lunga più veloce che sotto Ubuntu??

[darkbasic]

No.

[Emalele1688]

E' la risposta che mi sono dato da solo, evidentemente sarà per la diversa configurazione usata in compilazione ....
Grazie a tutti

[pabloski]

beh se lo compili con llvm di sicuro vai più veloce di gcc

[Gimli[2BV!2B]]

Vorresti quindi patchare i sorgenti della tua distribuzione con BFS?

Potrebbe funzionare, ma probabilmente le patch non sono compatibili.
È molto probabile che insistano su almeno un file comune, rendendo impossibile l'applicazione di tutte le modifiche da parte dello strumento patch.

Anche in caso di applicazione con successo non è garantito che le modifiche applicate dalla distribuzione siano compatibili con quelle della patch esterna.

Tirando le somme: nessuno ti impedisce di provare ma non te lo consiglierei.

[darkbasic]

Le patch delle varie distribuzioni in genere non vanno a toccare lo scheduler, e anche se lo facessero basterebbe non applicare quella determinata patch. Il punto è che non ne vedo il motivo: i vantaggi di BFS oggigiorno sono risibili e quando servono veramente latenze molto basse l'unica è andare di patchset realtime (fermo al 2.6.33 o a un 2.6.34 accrocchiato ). La buona notizia è che il ramo -rt sta subendo una grossa riscrittura e tenterà la strada verso il mainline

[Gimli[2BV!2B]]

Vero, le distribuzioni difficilmente toccano lo scheduler.
Però, per fare un esempio, considero probabile un conflitto nell'applicazione delle differenze alle voci di configurazione (init/Kconfig). Nell'esempio riportato non sembra accadere ma inciampa dopo.

Confermo che al momento sto usando un 2.6.38-rc8-git3 e, grazie al famoso TTY-based group scheduling, è abbastanza simile ad un kernel ck BFS (ma quando molto carico è sempre un po' più affannato).

Il real-time schietto di Ingo Molnár non l'ho mai provato: non mi ha interessato quando era ancora mantenuto, quindi, per il momento, ho perso il tram.
Se qualcosa si incamminerà verso il mainline ne sarò ben contento.

Originariamente inviato da LinuxOs

Una cosa interessante però l'ho notata nella configurazione relativa alla riga “Processor type and features” “Timer Frequency” in cui v'è un considerevole aumento (sino a 10000) rispetto al limite dei 1000.

Io ti consiglierei di non sforare i 2/3000 (personalmente mi accontento di 1000 + CONFIG_NO_HZ per aver un bell'idle tranquillo).
Il fatto è che aumentando quel valore aumenta l'overhead dovuto ai frequentissimi timer interrupt, con relativi potenziali cambi di contesto.
Non dovrebbe essere possibile notare differenze in meglio oltre il 1000 (è molto difficile che una persona normale colga ritardi di durata inferiore al millisecondo, ammetto però di non essermi messo lì a provare).

Nei 2.6.37 e 38 non mi risulta ci siano queste novità rt, ma ci sono voci che hanno nomi/descrizioni che potrebbero trarre in inganno.

[darkbasic]

Guardo io il kernel realtime lo uso tutte le settimane per fare registrazioni audio multitraccia e ti posso assicurare che è estremamente stabile. Il problema è che l'ultima patch è ormai molto datata, inoltre per uso desktop classico non ha senso secondo me.

[darkbasic]

Non uso driver proprietari, non saprei dirti.

[Gimli[2BV!2B]]

Originariamente inviato da LinuxOs

ho spuntato le voci kernel compression LZMA

Questa non la considero la scelta ottima: non serve comprimere tanto l'immagine del kernel, l'unico vantaggio è una vmlinuz più piccola ed usualmente si hanno giga di spazio a disposizione.
In termini di tempo questo comporterà un ritardo di una frazione di secondo in attesa dell'estrazione ed il risultato finale in temine di memoria occupata sarà identico qualsiasi sia l'algoritmo scelto.
La massima compressione è manna dal cielo per le distribuzioni e per installazioni su storage estremamente ristretto.
Io uso LZO, ma considero il classico GZIP una scelta altrettanto valida.
(a dirla tutta si sta spaccando in quattro un capello, ma cerco di spiegare ciò che sta dietro alle opzioni)

Originariamente inviato da LinuxOs

Per quanto riguarderebbe la dieta dimagrante, stavo pensado di usare l'utility http://cateee.net/autokernconf/ che dovrebbe sveltirmi e snellirmi il lavoro di ricerca e compilazione dei driver essenziali per il mio hardware.

Quello strumento mi sembra un po' datato. Puoi provare ad usarlo ma non sono molto ottimista sul risultato.
Personalmente non ho altri strumenti di questo tipo da suggerirti.

[Gimli[2BV!2B]]

Vero, però anche il contenuto del tar.gz di oggi mi risulta datato 8/1/2009... boh.

[Gimli[2BV!2B]]

Vedo 2200 differenze tra la mia configurazione e quella di make defconfig, immagino possano essercene anche di più tra quella di distribuzione e quella personalizzata.

Ti potrei sparare un Kompare (evitando diff liscio; io uso Kde4) ma non so se sia molto facile utilizzarlo sui .config del kernel.

Le voci sono relazionate tra loro da dipendenze e condizioni su stato modulo/integrato, quindi non credo sia comodo fare modifiche avendo come base le differenze di quei file.

Quando ne ho avuto bisogno ho confrontato le sezioni che mi interessavano di due configurazioni aprendo i due make menuconfig affiancati in due console.

[darkbasic]

Ma il vecchio caro lspci? Ci vogliono 5 minuti a trovare quei quattro moduli specifici per il tuo hardware, il problema è configurare tutto il resto del marasma che diventa sempre più grosso di release in release