|
prof. Nunzio Brugaletta |
atapSO |
EnneBi –
Computer Science
Avanti – Indietro – Inizio
Per poter permettere l'interazione fra i programmi e qualsiasi tipo di periferica al kernel si affiancano moduli software (driver) per la gestione delle periferiche in modo che esse siano trasparenti ai programmi: un programma scrive su una periferica al di là delle sue specifiche tecniche, sia essa, per esempio, un Hard Disk o una chiavetta USB.
Esistono due modi con cui un kernel può interagire con i driver:
modello monolitico: il kernel è un unico programma che contiene al suo interno tutti i driver per governare le periferiche. Tutti i driver girano assieme al kernel (in kernel-space) con il massimo dell'efficienza possibile
modello microkernel: il kernel è il più piccolo possibile e i driver girano (in user-space) come programmi qualsiasi
Nel kernel di Linux, originariamente sviluppato secondo il modello monolitico, i moduli per la gestione delle periferiche si possono caricare dinamicamente quando servono o, in alternativa, si possono includere nel kernel ricompilandoli con esso.
Dal punto di vista dell'utente si nota che una volta inserita una periferica, il sistema provvede a installarla in modo automatico. L'automatismo si basa su tre componenti:
il kernel: utilizza la directory virtuale /sys i cui file rappresentano informazioni sul kernel e non sono dati effettivamente esistenti nell'HD. Ogni device esistente nel sistema ha una directory nella /sys contenete file con informazioni sulle risorse allocate
il demone Udev: programma in esecuzione che non interagisce con l'utente (demone) che controlla la directory /sys, carica i moduli necessari alla gestione delle periferiche, genera un file associato ad ogni periferica nella /dev e notifica ad HAL la eventuale presenza di nuovi device
HAL (Hardware Abstraction Layer: strato di astrazione sull'hardware): gestisce un archivio delle periferiche e funziona da interfaccia fra queste e le applicazioni. Le applicazioni ricevono da HAL notifiche sulla presenza di nuove periferiche e interrogano HAL per conoscerne le caratteristiche.
L'utente può ottenere informazioni sull'hardware interrogando i file di log del kernel ovvero i file in cui il kernel annota il resoconto delle proprie attività (il diario di bordo del sistema).
$ dmesg | tail [ 20.660198] groups: 1 0 [ 22.948470] CPU0 attaching NULL sched-domain. [ 22.948476] CPU1 attaching NULL sched-domain. [ 22.968636] CPU0 attaching sched-domain: [ 22.968640] domain 0: span 0-1 level MC [ 22.968642] groups: 0 1 [ 22.968646] CPU1 attaching sched-domain: [ 22.968648] domain 0: span 0-1 level MC [ 22.968650] groups: 1 0 [ 30.304019] eth0: no IPv6 routers present $ dmesg | tail [ 4433.851997] scsi 4:0:0:0: Direct-Access SanDisk Cruzer Mini 0.2 PQ: 0 ANSI: 2 [ 4433.852857] sd 4:0:0:0: Attached scsi generic sg2 type 0 [ 4433.855604] sd 4:0:0:0: [sdb] 250879 512-byte logical blocks: (128 MB/122 MiB) [ 4433.856353] sd 4:0:0:0: [sdb] Write Protect is off [ 4433.856359] sd 4:0:0:0: [sdb] Mode Sense: 03 00 00 00 [ 4433.856363] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 4433.865863] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 4433.865874] sdb: sdb1 [ 4433.870844] sd 4:0:0:0: [sdb] Assuming drive cache: write through [ 4433.870852] sd 4:0:0:0: [sdb] Attached SCSI removable disk
Il comando dmesg consente la visualizzazione dei log del kernel. Nell'esempio è utilizzato (concatenato) con tail per visualizzarne le ultime righe. I file di log del sistema sono parecchio lunghi e qui interessavano le ultime righe scritte dal kernel dopo l'introduzione di una chiavetta USB.
Il primo output del comando è quello che si ottiene lanciando il comando prima di inserire la chiavetta, il secondo output è il risultato dello stesso comando ottenuto dopo l'introduzione della chiavetta. Dall'esame degli output si nota la marca della chiavetta e il device che il kernel associa ad essa (sdb). Il device può essere utilizzato per montare la chiavetta ed accedere ai dati contenuti in essa.
|
http://ennebi.solira.org |
ennebi@solira.org |