
Autoprobing dell Hardware e configurazione del sistema
======================================================

Partiamo da un esempio pratico: la configurazione della scheda audio.

I programmi/script utilizzati sono 3:
- soundprobe, eseguito al primo boot o al campio di configurazione, deve
  riconoscere e configurare automaticamente l'hardware;
- soundconfig, permette di aggiungere, modificare o cancellare la 
  configurazione di un determinato hardware;
- sound.service e' lo script di boot che legge i file di configurazione
  ed inizializza l'hardware (insmod) in modo appropriato;

soundprobe
soundprobe utilizza l'output di 'pnpdump' ed 'lspci' per verificare
la presenza di schede audio presenti nel sistema ma che non hanno ancora
un file di configurazione. E' compito di soundprobe creare in automatico
il file di configurazione e richiamare 'soundconfig' per permettere
all'utente di modificare le impostazioni automatiche.
Il problema principale di soundprobe e' attivare in automatico la
configurazione della scheda nel caso di schede PNP

soundconfig
soundconfig serve solo ad editare i file di configurazione. Esso deve:
- visualizzare la lista dei moduli configurati e se il modulo e' attivo;
- possibilita' di aggiungere manualmente un nuovo modulo da una lista;
- modificare le proprieta' del modulo;
- eliminare un modulo;
- provare a lanciare 'soundprobe' per l'autodetecting;

sound.service
sound service e' lo script di boot (/etc/init.d) che gestisce il sound system.
Esso deve enumerare tutti i file di configurazioni e caricare/scaricare
i relativi moduli. sound.service opera secondo le specifiche degli script
del sound.service.

L'utente ha quindi i seguenti vantaggi:
- configurazione automatica e personalizzabile delle periferiche;
- possibilita' di intervenire in qualsiasi momento sulla configurazione
  tramite il pannello di controllo.



PkgTool e TuxConf
=================

PkgTool e' un pacchetto che contiene diversi eseguibili e librerie,
pensato originariamente come replacement per il tool di setup riscritto
in C invece che in shell script, contiene ora moltissime funzioni di
utilita' in C.

PkgTool contiene:
- setup, il tool d'installazione pacchetti a riga di comando;
- caronte (parte 1), il tool d'installazione della distribuzione;

PkgTool conterra:
- caronte (parte 2)
- packagement, il tool di selezione dettagliata dei pacchetti;
- installer, il tool di installazione/rimozione dei pacchetti selezionati;
- wizard, il tool per la selezione dei pacchetti per profilo;

PkgTool utilizza:
- libhardware, libreria per l'accesso ai parametri del kernel e ad i file
  di configurazione che riguardano l'hardware della macchina;
- libuntar,  libreria per estrarre file da .tar.gz;
- libsystem, funzioni per eseguire comandi di sistema (mv,cp,rm -fR, etc.);
- libutils,  funzioni sulle stringe ed altro;
- libchain,  funzioni per la gestione di liste concatenate;



Tuxconf (ex AGX's User Profiles)
================================

Tuxconf contiene tutti i tool di configurazione riscritti in C
i programmi sono racchiusi in un unico pacchetto sorgente, ovviamente
in diverse subdirectory, perche' ovviamente condividono numerose
funzioni. Tuxconf ovviamente si appoggia anche alle altre librerie
presenti in PkgTool (libhardware,libsystem,libutils,etc).

soundprobe e soundconfig saranno parte di questo pacchetto e
dovranno integrarsi con libhardware.



libhardware da vicino
=====================

Introdurro' libhardware dall'esempio delle schede audio.
libhardware mette a disposizione una struttura di tipo TComputer,
questa struttura contiene dei campi che identificano i vari
device presenti nel proprio sistema. Nel nostro caso' conterra'
la lista delle schede audio configurate.

soundprobe dovrebbe chiamare la funzione 'probe_soundcards()', questa 
funzione deve prima chiamare 'query_soundcards()' per creare la lista
delle schede audio configurate manualmente. Quindi utilizzare i tool
'pnpdump' e 'lspci' per controllare la presenza di hardware non
configurato, nonche' controllapre /proc/sndstat per vericare la presenza
di moduli compilati direttamente nel kernel.
soundprobe quindi crea in automatico il file di configurazione per
ogni scheda trovata.
soundconfig, invece, usa libhardware per ottenere la lista delle sole
schede configurate e le operazioni per effettuare aggiunte, modifiche,
cancellazioni.


Un altro esempio efficiente potrebbe essere modemprobe, un'ipotetico 
programma per la configurazione del proprio modem. modemprobe utilizza 
la funzione 'probe_serial_modems()' per localizzare i modem. Come puo' 
essere fatto ?
probe_serial_modem esegue 'query_serial_ports()' per ottenere
l'elenco delle porte seriali configurate nella struttura 
mycomputer->serial_ports, quindi, su ogni porta seriale, viene inviata
la stringa di inizializzazione 'ATZ' e rimane in attesa per un 
determinato timeout (2 secondi) della risposta di 'OK' da parte del
modem.

In generale avremo funzioni del tipo:
- query_<device>, che ritornano informazioni sui device configurati;
- probe_<device>, che provano a determinare la presenza di alcuni device
  ben conosciuti;
queste operazioni sono in sola lettura sui file di configurazione
possiamo ipotizzare di avere
- add_<device>, per aggiungere la configurazione di un device;
- delete_<device>, per rimuoverla;
- change_<device>, per cambiarla/riscriverla;



E per le schede PNP ?
Aspettando il kernel 2.4 con il supporto per il PNP integrato
occorrera creare un front-end alle isapnputils che ricavano dal file
le configurazioni dei vari devices per poter scegliere tra le varie
combinazioni di IRQ/IO/PORTE possibili per lo stesso device.



Configurazione della scheda audio (esempio)
===========================================

I settaggi delle schede audio sono salvati in 
  /etc/badpenguin/$PROFILE/$NOMESCHEDA.soundcard

Lo script /etc/init.d/sound.service si preoccupa di verificare la presenza
di almeno una scheda audio e di caricarne tutti i moduli prerequisiti
(soundcore.o, soundlow.o, sound.o)

Il file /etc/aliases.conf non va utilizzato, si utilizza invece lo
script/funzione 'install-module' per passargli tutti i parametri necessari.

Esempio di implementazione di install-module:

install-module() {

  # Controllo presenza modulo
  lsmod | grep -q $1
  if [ $? -eq 0 ]; then
    echo "Modulo '$1' gia' caricato"
    return 0
  fi

  echo "Caricamento modulo '$1'"
  insmod $*
  REPLY=$?
  if [ $REPLY -ne 0 ]; then
    echo "Errore durante il caricamento del modulo '$1'"
    exit $REPLY
  fi
  return 0
}

In questa forma install-module esce autonomamente in caso di errore
durante il caricamento di uno dei moduli prerequisiti. Si puo'
anche implementare come script a parte, ma in questo caso bisogna
testare il return code su ogni riga, ammettendo di dover generare
il file $SOUNDCARD.module da un'altro script questa sembra essere
la soluzione migliore.

Continuiamo ...

Lo script sound.service deve supportare i vari parametri 'start', 'stop', 
'restart', 'reload', 'configure' previsti dalle specifiche sui servizi.
In start ovviamente vengono caricati i moduli basi del sound
e quelli della scheda audio, facendo attenzione a non caricare
due volte gli stessi moduli:

possiamo ipotizzare questa struttura per la parte di 'start':
  ...
  # Carica funzioni, tra cui install-module
  . /etc/init.d/module-manager.inc
  # Controlla installazione almeno 1 scheda audio
  if [ -f /etc/badpenguin/$PROFILE/*.soundcard ]; then
    # Carica Linux Sound System
    install-module soundcore
    install-module soundlow
    install-module sound
    # Sound Blaster 16 ?
    if [ -f /etc/badpenguin/$PROFILE/sb16.soundcard ]; then
      . /etc/badpenguin/$PROFILE/sb16.soundcard
      install-module uart401
      install-module sb IO=$IO IRQ=$IRQ DMA=$DMA DMA16=$DMA16
    fi
    # OPL3
    if [ -f /etc/badpenguin/$PROFILE/opl3.soundcard ]; then
      . /etc/badpenguin/$PROFILE/opl3.soundcard
      install-module opl3 IO=$IO
    fi
  fi
  ...

Premesso che si puo sempre aggiungere un .module manualmente
in qualsiasi momento, da parte dell'utente io preferirei avere
un'unico tool che carica i driver delle schede audio, anche per
non dover gestire due volte le stesse informazioni.



Conclusione
===========
I discorsi illustrati per le schede audio sono validi per tutta
una serie di altri device (SCSI, schede di rete, etc.)
ed e' auspicabile gestire questi device nello stesso modo.

I device SCSI devono essere configurati prima dello script di mountall,
quindi appena il fs di / e' montato RW

Le schede di rete sono molto simili alle schede audio, ad esempio
molte dipendono dal modulo 8390 (???), ed e' applicabile lo stesso
procedimento.

Per le stampante una cosa davvero figa :-) sarebbe quella di poter 
riconoscere il modello tramite la porta parallela (parport)

Per i modem ho visto che la RedHat cerca sulle seriali mandando la
stringa ATH ed aspettando l'OK di risposta.

Per i mouse qualcuuno ha delle idee ?

Ha, per la scheda video vale quanto scritto per XFree86config, non viene
fatto in automatico ma su richiesta dal menu.

