# [info] 2.6.X, moduli (alsa, usb) e altro.

## motaboy

Questa è più che altro un'informazione e una curiosità per vedere se cosa dico è valido e dove sono le eccezioni.

Sono un maniaco del kernel-2.6 e infatti lo sto usando stabilmente già a partire dalla beta1.

Dato che mi piace smacchinare e capire come funziona ho deciso di fare varie prove per vedere fino a che punto l'hotplug è valido.

Ho cosi osservato varie cose:

Quasi tutti i moduli del kernel 2.6 registrano la struttura "pci_driver" in cui riportano i vari id dei device da loro supportati (per maggiori informazioni vedere il file "/usr/src/linux/Documentation/pci.txt")

Allora ho pensato, ma quindi è inutile caricare  i moduli con modules.autoload se sono i moduli stessi a dire quali device supportano ed a trovarli.

Perciò ho fatto una bella prova: Ho cancellato totalmente il file alsa de /etc/modules.d/alsa, in questo file avevo (come da guida) creato l'alias "alias snd-card-0 snd-via82xx" per il mio chipset audio, poi ho rimosso anche /etc/init.d/alsasound dal runlevel di boot (questo perchè alsasound usa un metodo "bastardo" in cui legge gli alias riportati da "modprobe -c" e tramite un grep e carica i moduli alsa"), ho poi fatto il reboot e per magia hotplug mi carica lo stesso tutte le cose relative ad alsa (ovviamente senza alsasound non ripristina i volumi ma questa è un'altra cosa, e poi ci pensa kmix a ripristinarli)

Lo stesso avviene coi device usb (persino proprio uhci_hcd, ohci_hcd ed ehci_hcd usbcore proprio grazie alla struttura pci_driver definita da loro, per esempio vedi "/usr/src/linux/drivers/usb/host/uhci-hcd.c" )

Ovviamente questo avviene anche coi kernel 2.4.0 ma solo per pochi moduli pci (gli usb sono stati i primi a gestire l'hotplug).

Non so se a qualcuno interessa e sfortunatamente ho pochissime periferiche con cui provare e mi piacerebbe che qualcun'altro confermasse facendo delle prove ciò che ho visto (tipo schede ethernet, controller scsi ecc...)

Credo che ciò sia una grande cosa in vista di un futuro più "desktop" per linux per il fatto che in questo modo anche un principiante (ma non solo) risolverà molti dei suoi problemi per la gestione delle periferiche (che modulo devo caricare? come faccio a saperlo? dove lo trovo? ecc...).

Per concludere: Scusate se vi ho annoiato.   :Laughing:   :Laughing: 

Bye!

----------

## cerri

Ma quale annoiato  :Smile: 

----------

## motaboy

 *cerri wrote:*   

> Ma quale annoiato 

 

 :Laughing: 

Adesso ho fatto la prova del fuoco: Ho rimosso (o meglio dire cambiato nome) "/etc/modules.d" e poi ho lanciato "modules-update" in modo che modules.conf fosse un bellissimo file vuoto. Ho poi riavviato e come mi aspettavo il sistema non fa una piega e mi carica tutti moduli che mi servono. 

L'unico che non carica è quello dell'nvidia proprio per il fatto che esso non esporta nessun id. Perciò ho dovuto lasciare i 2 alias relativi all'nvidia.

Cmq se uno volesse vedere tutti gli alias, simboli ed id esportati dai moduli basta guardare i file " modules.* " presenti in "/lib/modules/kernel-corrente" che vengono generati da depmod (presente nelle module-init-tools).

Bye!

----------

## motaboy

Tanto per continuare ad annoiarvi ho datto un'altra prova andando come sempre contro la guida di alsa.

Ho spostato l'esecuzione dello script rc "alsasound" dal runlevel di boot a quello di default. In questo modo lascio che i moduli di alsa vengano caricati da hotplug, poi parte alsasound il quale vede che i moduli sono già caricati a quindi ripristina solamente i livelli del mixer, scrivendo:

```

* ALSA Detected...

* Restoring Mixer Levels

```

In questo modo avviamente non vengono caricati i moduli per l'emulazione OSS (ma ho visto che oramai tutti i programmi funzionano benissimo senza OSS perchè tutti usano le api di alsa), per fare questo bisogna inserire gli alias appositi in modules.conf ma questa è una cosa giusta perchè non ha senso che i moduli ALSA esportino automaticamente gli alias per OSS, visto che questa è una feature opzionale.

P.S.

Mi piacerebbe che qualcuno provasse queste soluzioni anche con altri hardware che io non possiedo per vedere se sono valide o salamente che mi scrivesse qualcosa del tipo "Stai dicendo un mucchio di cazzate...".  :Laughing: 

Bye!

----------

## Ash y Nod

No cazzate non le dici almeno per quanto riguarda alsa...

Ho tolto alsa dal runlevel e commentato come hai detto tu in testa al primo articolo, e al reboot KDE funziona benissimo l'audio.

Al contrario di tutto quello che avevo provato prima

----------

## cerri

Bene, sposto anch'io alsa va.

----------

## motaboy

 *Ash y Nod wrote:*   

> No cazzate non le dici almeno per quanto riguarda alsa...
> 
> Ho tolto alsa dal runlevel e commentato come hai detto tu in testa al primo articolo, e al reboot KDE funziona benissimo l'audio.
> 
> Al contrario di tutto quello che avevo provato prima
> ...

 

 *cerri wrote:*   

> Bene, sposto anch'io alsa va.

 

Grazie, questo mi è di conforto.   :Laughing:  Se vuoi caricare lo stesso i volumi indipendentemente da kmix puoi far partire alsasound dal runlevel di default. 

Adesso stavo smacchinando con il bluetooth (vedi il mio avatar).

Ho visto che se il sistema parte senza il dongle usb collegato lo script rc per il bluetooth non riesce a caricare hcid e sdpd per il motivo che essendo il mio modules.conf vuoto non sono definiti gli alias per il bluetooth (alias net-pf-31 bluetooth) e quindi visto che hcid necessita del modulo bluetooth esso non viene caricato. Questo perchè è il modulo bluetooth stesso ad esportare gli alias necessari a hcid ed sdpd.

Perciò credo che la soluzione giusta sia usare invece di uno script di init, uno script di hotplug che carichi i due demoni solo quando viene collegato un dispositivo bluetooth.

Adesso studio il modo di farlo e se funziona la posto.

Bye!

----------

## cerri

 *motaboy wrote:*   

> Perciò credo che la soluzione giusta sia usare invece di uno script di init, uno script di hotplug che carichi i due demoni solo quando viene collegato un dispositivo bluetooth.
> 
> Adesso studio il modo di farlo e se funziona la posto.

 

Ma questo non dovrebber già farlo il kernel? Ovviamente se è abilitata l'opzione di caricare automaticamente i moduli. Non ho devices bluetooth da provare, solo integrato...

----------

## shev

Visto che volevi feedback anche da altre architetture, prima di sera ci provo sul ppc  :Wink: 

----------

## motaboy

 *cerri wrote:*   

> 
> 
> Ma questo non dovrebber già farlo il kernel? Ovviamente se è abilitata l'opzione di caricare automaticamente i moduli. Non ho devices bluetooth da provare, solo integrato...

 

Si infatti, quando conneto il dongle vengono caricati tutti i moduli necessari (bluetooth, hci_usb, l2cap, rfcomm ...).

Il problema è che durante l'init del sistema viene caricato lo script bluetooth che si occupa di far partire hcid ed sdpd, ma questi 2 falliscono perchè non riescono ad aprire un socket hci (hcid) e l2cap (sdpd) che vengono forniti dal modulo "bluetooth" ed "l2cap" perchè questi non sono caricati.

Se avessi in modules.conf i seguenti alias:

```

alias net-pf-31 bluetooth

alias bt-proto-0 l2cap

alias bt-proto-3 rfcomm

alias bt-proto-4 bnep

```

succederebbe che quando hcid tenta di aprire un socket hci che è associato nel kernel al protocollo  net-pf-31 allora verrebbe caricato il modulo bluetooth e hcid termina correttamente.

Visto che per scelta ho deciso di abolire tutti gli alias in modules.conf, visto che essi vengono automaticamente creati quando carico il modulo (per esempio "bluetooth" esporta questo: "alias net-pf-31 bluetooth", l2cap esporta questo: "alias bt-proto-0 l2cap" ed rfcomm questo: "alias bt-proto-3 rfcomm") devo avviare hcid ed sdpd non all'init (quando il dispositivo potrebbe non essere ancora collegato) ma quando esso viene collegato.

E' un pò come il famoso script di hotplug che monta automaticamente le memory stick quando le colleghi.

Ho la mente un po contorta...   :Laughing: 

Bye!

----------

## motaboy

 *Shev wrote:*   

> Visto che volevi feedback anche da altre architetture, prima di sera ci provo sul ppc 

 

Grassie.   :Laughing: 

Bye!

----------

## motaboy

Il fato...

Proprio adesso sulla mailing list bluez-devel stanno parlando di fare partcire hcid e sdpd con uno script di hotplug.

Marcel Holtmann (che è il mantainer di bluez) sta facendo elegantemente notare che è una stronzata...

E infatti potrebbe avere ragione.

A PARTE QUESTO HO SCOPERTO UN SACCO DI COSE:

1) hcid e sdpd dovrebbero funzionare per il fatto che se i moduli esportano i famosi alias, li esportano per 1 motivo: quello di poter essere caricati quando qualcuno necessita di una "funzione" resa disponibile da essi. 

Il problema è che questi alias non vengono gestiti nella maniera corretta.

Infatti o li dichiari esplicitamente in "/etc/modules.conf" o QUALCUNO deve prendere i file in "/lib/modules/modules.alias, modules.symbols e altri), questo qualcuno esiste e si chiama "modprobe -c".

Infatti se fate modprobe -c esso da in uscita tutti gli alias trovati.

Ora seguitemi...

In gentoo c'è un programma preso da Debian che si chiamate modules-update (o update-modules che è un simlink ad esso). Questo programma prende i file contenuti in /etc/modules.d e li concatena insieme in unico file chiamato /etc/modules.conf, 

MA NON E' FINITA.

Dopo di ciò chiama uno script presente nelle module-init-tools chiamato 

"generate-modprobe.conf" che prende l'output di "modprobe.old -c" e tramite un parsing strano genera "/etc/modprobe.conf"

Il problema è proprio che prende l'output di modprobe.old, ossia del vecchio modprobe, quello che va bene per i kernel 2.4, ma che da fuori risultati sbagliati, per esempio nel 2.6 avrei 

```

alias net-pf-31 bluetooth

```

mentre "modprobe.old -c" mi da

```

alias net-pf-31 bluez

```

ed essendo i valori di /etc/modprobe.conf quelli che sovrascrivono altri presenti è per questo che "hcid" ed "sdpd" falliscono perchè non viene creato il file corretto.

Come ho risolto? SEMPLICE.

1) Cancella qualsiasi traccia di modprobe.conf 

2) edita "/etc/init.d/modules" che è lo script che chiama modules-update all'avvio (quando scrive "Calculating modules dependencies") da

```

 ebegin "Calculating module dependencies"

        /sbin/modules-update &>/dev/null

        eend $? "Failed to calculate dependencies"

```

a

```

 ebegin "Calculating module dependencies"

        #/sbin/modules-update &>/dev/null

        eend $? "Failed to calculate dependencies"

```

in modo da non farlo eseguire.

Perciò al riavvio "/etc/modprobe.conf" non verrà creato.

Ma non c'è nessun problema visto che le NUOVE module-init-tools usano i file presenti in "/lib/modules/kernel-corrent/" per le dipendenze e gli alias, ossia i soliti "modules.*", e non gliene frega niente di modprobe.conf se non viene creato.

Ovviamente funziona tutto a parte il solito driver dell'nvidia che non esporta nessun alias perchè è bastardo e closed.

Che ne dite? Devo essere internato?   :Shocked: 

E sopratutto, come faccio a spiegare in inglese una cosa del genere? Per esempio al mantainer degli script di init senza essere fucilato?  :Laughing: 

Bye!

----------

## motaboy

Ormai gli ho scritto tutta la pappardella...

RISPOSTA = Correntemente le cose sono in uno stato instabile, cosi per adesso è meglio mantenere tutto come è, anche perchè bisogna gestire contemporaneamente sia i kernel 2.4 che i 2.6, perciò ho bisogno di sedermi e pensarci su.

Una buona cosa sarebbe quella di fare un bug-report, cosi che ciò che hai detto non verrà dimenticato e mi ricorderò di guardarci.

```

# strip RISPOSTA

   "Non rompere le balle!"

```

 :Laughing:   :Laughing: 

Infatti ha ragione perchè le module-init-tools sono ancora in fase "pre" e guardando il sorgente molte cose devono essere modificate.

Io intanto continuo a documentarmi perchè ho già in mente un pò di cose...

Bye!

----------

## Sparker

Resuscito questo post  :Smile: 

Non credo sia possibile, per ora eliminare modprobe.conf

Alcuni device hanno bisogno di alcune opzioni passate tramite modprobe per funzionare correttamente. Ad esempio possiedo una scheda TV che utilizza bttv e per farla funzionare devo mettere:

```
alias char-major-81-0 bttv

options bttv pll=1 radio=0 card=6

options tuner type=5

```

con le opzioni non corrette non solo non funziona, ma pianta la macchina!!!

Se c'è un altro modo "più udev" per passare opzioni sarei felicissimo di essere smentito   :Wink: 

----------

## motaboy

Non so se ci sono altri modi di specifiare un'opzione per un modulo. Infatti in questi casi credo che modprobe.conf sia indispensabile. 

Quello che non è indispensabile (se le module-init-tools funzionassero) sono tutti gli alias tipo 

alias char-major-81-0 bttv 

perchè essendo il modulo stesso a dichiarare gli alias che fornisce non è più necessario dichiararli a mano.

Non so se bttv esporta già l'alias però se vedi in /lib/modules/`uname -r`/modules.alias vedrai tutti gli alias esportati dai moduli.

Bye!

----------

## Sparker

Capito.

Ora provo una configurazione alias-less.

Grazie di tutte le info!

----------

## motaboy

Ok. Allora ti faccio un riassuntino di quello che ho scoperto da quando ho aperto il thread.

All'avvio (init) viene chiamato lo script /etc/init.d/modules

Questo quando scrive "Calculating module dependencies" chiama lo script "/sbin/modules-update" esso a sua volta, nel caso veda che si tratta di kernel 2.5-2.6 chiama lo script /sbin/generate_modprobe.conf.

Cosa fa?

"generate_modprobe.conf" utilizza le vecchie versione delle modutils, ossia chiama "modprobe.old -c" con questa opzione esso dovrebbe convertire il VECCHIO file "modules.conf" nel NUOVO (ossia quello che viene usato dal nuovo modprobe) "modprobe.conf", qua però sorgono alcuni problemi. Infatti nel caso del bluetooth il modulo ha cambiato nome da bluez a bluetooth. Il vecchio modprobe.old ha però una lista interna di alias standard che si possono trovare nel file "/modutils-2.4.26/util/alias.h", in questo file è gia definito l'alias: "net-pf-31 bluez"

Visto che gli alias di modprobe.conf hanno la precedenza su quelli di /lib/modules/`uname -r`/modules.alias allora non viene considerato l'alias corretto, ovvero: "net-pf-31 bluetooth"

Quale è la soluzione corretta?

Io credo che la soluzione corretta sia non fare chiamare il programma "generate_modprobe.conf", in questo modo "modules.conf" non serve più a niente, cosi come tutti i files sotto /etc/modules.d (io li go proprio rinominati per dimostrare che funziona) e puoi editarti a mano il file modprobe.conf (che altrimenti verrebbe sovrascritto da "generate_modprobe.conf"), nel mio caso esso è facile: è vuoto. Nel tuo caso probabilmente dovrai aggiungere la scritta:

```

options bttv .....

```

Infatti tutti gli alias che mi servono sono esportati dai moduli stessi (Rusty Russel che è quello che ha fatto le nuove module-init-tools, insieme a ipchains e netfilter, ne sa abbastanza  :Smile:  ).

Come fare a non fare chiamare "generate_modprobe.conf"?: lo cancelli e fai in modo che resti cancellato, oppure modifichi "/sbin/modules-update" in modo che non lo chiami. attenzioni a quando fai un update delle module-init-tools a ricancellarlo oppure potrebbe sovrascrivert il tuo modprobe.conf (fare backup).

Credo che questo sia il VERO modo di gestire i moduli coi kernel 2.6. 

Spero che tutto ti sia chiaro e utile, altrimenti chiedi pure.

Bye!

----------

