Panoramica Generale

()

L’architettura di base.

Contrariamente ad altri sistemi operativi, GNU/Linux nasce, come tutti gli Unix, come sistema multitasking e multiutente.

Questo significa che GNU/Linux ha un’architettura di sistema che e stata pensata n dall’inizio per l’uso contemporaneo da parte di piu utenti. Questo comporta conseguenze non del tutto intuitive nel caso in cui, come oggi accade sempre piu spesso, esso venga usato come stazione di lavoro da un utente singolo.

Il concetto base dell’architettura di ogni sistema Unix come GNU/Linux è quello di una rigida separazione fra il kernel (il nucleo del sistema), cui si demanda la gestione delle risorse hardware (come la CPU, la memoria, le periferiche) ed i processi, (le unita di esecuzione dei programmi), che nel caso vanno dai comandi base di sistema, agli applicativi, alle interfacce per l’interazione con gli utenti.

Lo scopo del kernel infatti è solo quello di essere in grado di eseguire contemporaneamente molti processi in maniera efficiente, garantendo una corretta distribuzione fra gli stessi della memoria e del tempo di CPU, e quello inoltre di fornire le adeguate interfacce software per l’accesso alle periferiche della macchina e le infrastrutture di base necessarie per costruire i servizi.

Tutto il resto, dall’autenticazione all’interfaccia utente, viene realizzato usando processi che eseguono gli opportuni programmi.

Questo si traduce in una delle caratteristiche essenziali su cui si basa l’architettura dei sistemi Unix: la distinzione fra il cosiddetto user space, che è l’ambiente a disposizione degli utenti, in cui vengono eseguiti i processi, e il kernel space, che e l’ambiente in cui viene eseguito il kernel.

I due ambienti comunicano attraverso un insieme di interfacce ben definite e standardizzate; secondo una struttura come quella mostrata in figura

Questa architettura prevede che solo il kernel viene eseguito in modalità privilegiata, ed e l’unico a poter accedere direttamente alle risorse dell’hardware.

I normali programmi invece vengono eseguiti in modalità protetta, in un ambiente virtuale, l’user space, in cui essi vedono se stessi come se avessero piena disponibilità della CPU e della memoria, ma in cui possono accedere alle periferiche e alle altre funzionalità messe a disposizione del kernel solo attraverso una serie di funzioni di sistema standardizzate, dette system call.

Lo standard in questo caso si chiama POSIX.1; ma oltre a quelle dello standard Linux supporta ulteriori system call, relative a sue estensioni specifiche.

Le system call e tutta una serie di ulteriori funzioni di base sono tradizionalmente raccolte in un’unica libreria che pertanto diventa essenziale per il funzionamento di qualunque programma è la GNU C library (chiamata in breve glibc), che costituisce una delle parti fondamentali del sistema.

In sostanza quello che succede è che l’unico vero programma che viene eseguito e’ il kernel, che si incarica di costruire questo ambiente virtuale in cui far girare gli altri programmi.

Una parte del kernel, come lo scheduler, deputato della gestione del tempo di processore, provvederà a decidere volta per volta qual e il processo che deve essere eseguito in un determinato momento (realizzando cos il multitasking).

Una seconda parte,come la VM (sigla che sta per Virtual Memory), si occupa invece di gestire l’uso della memoria disponibile.

La memoria virtuale e uno dei sottosistemi più importanti del kernel, oggetto di continui miglioramenti in quanto critico per tutte le prestazioni del sistema, perchè e quella che fa in modo che ogni processo veda uno spazio di indirizzi proprio che poi viene rimappato nella memoria fisica e effettivamente presente, così che sia impossibile che un processo possa accedere alla memoria di un altro processo.

La memoria virtuale si incarica anche di gestire, in caso di esaurimento della RAM, l’eventuale spostamento delle pagine di memoria meno usate su uno opportuno spazio disco (lo swap,) evitando di fermare l’esecuzione di un processo per una temporanea mancanza di memoria.

Infine c’e un’ultima parte del kernel,con l’indicazione generica driver anche se in realtà non e un unico sottosistema come le precedenti ma, un insieme di n\moduli” che consentono la gestione delle varie periferiche, fornendo un accesso alle stesse per conto dei programmi.

Questa parte, permette di definire una interfaccia di accesso generica per i dispositivi, cui spesso si fa riferimento dicendo che in un sistema unix-like \tutto e un file”.

La conseguenza piu importante di questa separazione fra user space e kernel space e’ che in questo modo non e possibile che un singolo programma possa disturbare l’azione di un altro programma o del kernel stesso, e questo è il principale motivo della stabilità di un sistema Unix nei confronti di altri sistemi in cui i processi non hanno di questi limiti, o vengono, per vari motivi, eseguiti all’interno del kernel.

Introduzione

Sin dagli albori dell’informatica, i produttori di personal computer integrano una gran varietà di parti hardware nei loro sistemi, che a loro volta devono essere supportate dal sistema operativo. Questa eterogeneità rischia di essere troppo impegnativa dal punto di vista dello sviluppatore del sistema stesso, a meno che l’industria non stabilisca standard per i set di istruzioni e la comunicazione dei dispositivi.

Analogamente al livello di astrazione standardizzato fornito dal sistema operativo a un’applicazione, questi standard semplificano la scrittura e la manutenzione di un sistema operativo non legato a un modello di hardware specifico.

Tuttavia, la complessità dell’hardware richiede a volte aggiustamenti su come le risorse debbano essere interfacciate con il sistema operativo, in modo che possa essere installato e funzionare correttamente.

Alcune di queste regolazioni possono essere eseguite anche senza un sistema operativo installato.

La maggior parte delle macchine offre un’utilità di configurazione che può essere eseguita all’accensione della macchina stessa. Fino alla metà degli anni 2000, l’utilità di configurazione era implementata nel BIOS (Basic Input / Output System), lo standard per il firmware contenente le routine di configurazione di base presente nelle schede madri x86.

Dalla fine del primo decennio degli anni 2000, le macchine basate sull’architettura x86 hanno iniziato a sostituire il BIOS con una nuova implementazione chiamata UEFI (Unified Extensible Firmware Interface), che ha funzionalità più sofisticate per l’identificazione, il test, la configurazione e gli aggiornamenti del firmware. Nonostante la modifica, non è raro chiamare ancora l’utilità di configurazione con il nome di BIOS, poiché entrambe le implementazioni soddisfano lo stesso scopo di base.

L’Attivazione delle Periferiche

L’utilità di configurazione del sistema viene visualizzata dopo aver premuto un tasto specifico all’accensione del computer.

Quale tasto premere varia da produttore a produttore, ma di solito è Canc o uno dei tasti funzione, come F2 o F12. La combinazione di tasti da utilizzare viene spesso visualizzata nella schermata di accensione.

Nell’utilità di configurazione del BIOS è possibile abilitare e disabilitare le periferiche integrate, attivare la protezione degli errori di base e modificare le impostazioni hardware come IRQ (Interrupt ReQuest) e DMA (Direct Memory Access).

La modifica di queste impostazioni è raramente effettuata sulle macchine moderne, ma potrebbe essere necessario apportare modifiche per risolvere problemi specifici.

Esistono tecnologie RAM, per esempio, compatibili con velocità di trasferimento dati più elevate rispetto ai valori predefiniti, quindi si consiglia di modificarlo con i valori specificati dal produttore. Alcune CPU offrono funzionalità che potrebbero non essere necessarie per l’installazione specifica e che possono essere disattivate.

Le funzioni disabilitate riducono il consumo di energia e possono aumentare la protezioni del sistema, disabilitando per esempio funzioni della CPU contenenti bug noti.

Se la macchina è dotata di molti dispositivi di archiviazione, è importante definire quale abbia il bootloader corretto e dovrebbe essere la prima voce nell’ordine di avvio. Il sistema operativo potrebbe non caricarsi se il dispositivo errato viene visualizzato per primo nell’elenco dell’avvio del BIOS.

Il Controllo delle Periferiche in Linux

Una volta identificati correttamente i dispositivi, spetta al sistema operativo associare i componenti software corrispondenti richiesti da essi. Quando una funzionalità hardware non opera come previsto, è importante identificare dove si stia verificando esattamente il problema.

Quando un componente hardware non viene rilevato dal sistema operativo, è molto probabile che esso — o la porta a cui è collegato — sia difettoso.

Quando il componente hardware viene rilevata correttamente, ma continua a non funzionare, potrebbe esserci un problema sul fronte sistema operativo.

Pertanto, uno dei primi passi, quando si affrontano i problemi relativi all’hardware, è verificare se il sistema operativo stia rilevando correttamente il dispositivo.

Esistono due modi di base per identificare le risorse hardware su un sistema Linux: usare comandi specifici o leggere file specifici all’interno di filesystem speciali.

I Comandi di Ispezione

I due comandi essenziali per identificare i dispositivi collegati in un sistema Linux sono:lspci

Mostra tutti i dispositivi attualmente collegati al bus PCI (Peripheral Component Interconnect). I dispositivi PCI possono essere un componente collegato alla scheda madre, come un controller del disco, o una scheda di espansione inserita in uno slot PCI, come una scheda grafica esterna.lsusb

Elenca i dispositivi USB (Universal Serial Bus) attualmente collegati alla macchina. Sebbene esistano dispositivi USB per quasi tutti gli scopi immaginabili, l’interfaccia USB è ampiamente utilizzata per collegare dispositivi di input — tastiere, dispositivi di puntamento — e supporti di archiviazione rimovibili.

L’output dei comandi lspci e lsusb consiste in un elenco di tutti i dispositivi PCI e USB identificati dal sistema operativo. Tuttavia, il dispositivo potrebbe non essere ancora completamente operativo, poiché ogni parte hardware richiede un componente software per controllare il dispositivo corrispondente. Questo componente software è chiamato kernel module e può far parte del kernel Linux ufficiale o essere aggiunto separatamente da altre fonti.

I moduli del kernel Linux relativi ai dispositivi hardware sono anche chiamati drivers, come in altri sistemi operativi. I driver per Linux, tuttavia, non sono sempre forniti dal produttore del dispositivo. Mentre alcuni produttori forniscono i propri driver binari da installare separatamente, molti altri sono scritti da sviluppatori indipendenti. Storicamente, i componenti che funzionano su Windows, per esempio, potrebbero non avere un modulo kernel controparte per Linux. Al giorno d’oggi, i sistemi operativi basati su Linux hanno un forte supporto hardware e la maggior parte dei dispositivi funziona senza sforzo.

I comandi direttamente correlati all’hardware richiedono spesso i privilegi di root per essere eseguiti o mostreranno informazioni limitate se eseguiti da un utente normale, quindi potrebbe essere necessario effettuare il login come root o eseguire il comando con sudo.

Il seguente output del comando lspci, per esempio, mostra alcuni dispositivi identificati:

$ lspci
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
04:04.0 Multimedia audio controller: VIA Technologies Inc. ICE1712 [Envy24] PCI Multi-Channel I/O Controller (rev 02)
04:0b.0 FireWire (IEEE 1394): LSI Corporation FW322/323 [TrueFire] 1394a Controller (rev 70)

L’output di tali comandi può essere lungo decine di righe, quindi gli esempi precedenti e successivi contengono solo le sezioni di interesse. I numeri esadecimali all’inizio di ogni riga sono gli indirizzi univoci del corrispondente dispositivo PCI. Il comando lspci mostra maggiori dettagli su un dispositivo specifico se il suo indirizzo è fornito con l’opzione -s, accompagnato dall’opzione -v

$ lspci -s 04:02.0 -v
04:02.0 Network controller: Ralink corp. RT2561/RT61 802.11g PCI
    Subsystem: Linksys WMP54G v4.1
    Flags: bus master, slow devsel, latency 32, IRQ 21
    Memory at e3100000 (32-bit, non-prefetchable) [size=32K]
    Capabilities: [40] Power Management version 2
    kernel driver in use: rt61pci

L’output ora mostra molti più dettagli del dispositivo sull’indirizzo 04: 02.0. È un controller di rete, il cui nome interno è Ralink corp. RT2561 / RT61 802.11g PCISubsystem è associato alla marca e al modello del dispositivo Linksys WMP54G v4.1 e può essere utile a fini diagnostici.

Il modulo del kernel può essere identificato nella riga kernel driver in use, che mostra il modulo rt61pci. Da tutte le informazioni raccolte, è corretto presumere che:

  1. Il device è stato identificato.
  2. Un modulo del kernel corrispondente è stato caricato.
  3. Il device dovrebbe essere pronto all’uso.

Un altro modo per verificare quale modulo del kernel è in uso per il dispositivo specificato è fornito dall’opzione -k, disponibile nelle versioni più recenti di lspci:

$ lspci -s 01:00.0 -k
01:00.0 VGA compatible controller: NVIDIA Corporation GM107 [GeForce GTX 750 Ti] (rev a2)
    kernel driver in use: nvidia
    kernel modules: nouveau, nvidia_drm, nvidia

Per il dispositivo prescelto, una scheda NVIDIA GPU, lspci dice che il modulo in uso è chiamato nvidia, alla riga kernel driver in use: nvidia e tutti i corrispondenti moduli del kernel sono elencati nella riga kernel modules: nouveau, nvidia_drm, nvidia.

Il comando lsusb è simile a lspci, ma elenca esclusivamente le informazioni USB:

$ lsusb
Bus 001 Device 029: ID 1781:0c9f Multiple Vendors USBtiny
Bus 001 Device 028: ID 093a:2521 Pixart Imaging, Inc. Optical Mouse
Bus 001 Device 020: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter
Bus 001 Device 011: ID 04f2:0402 Chicony Electronics Co., Ltd Genius LuxeMate i200 Keyboard
Bus 001 Device 007: ID 0424:7800 Standard Microsystems Corp.
Bus 001 Device 003: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 002: ID 0424:2514 Standard Microsystems Corp. USB 2.0 Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Il comando lsusb mostra i canali USB disponibili e i dispositivi ad essi collegati. Come con lspci, l’opzione -v mostra un output più dettagliato. Un dispositivo specifico può essere selezionato per l’ispezione fornendo il suo ID all’opzione -d:

$ lsusb -v -d 1781:0c9f
Bus 001 Device 029: ID 1781:0c9f Multiple Vendors USBtiny
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.01
  bDeviceClass          255 Vendor Specific Class
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x1781 Multiple Vendors
  idProduct          0x0c9f USBtiny
  bcdDevice            1.04
  iManufacturer           0
  iProduct                2 USBtiny
  iSerial                 0
  bNumConfigurations      1

Con l’opzione -t, il comando lsusb mostra le attuali mappature dei dispositivi USB come una struttura gerarchica ad albero:

$ lsusb -t
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 1: Dev 3, If 0, Class=Hub, Driver=hub/3p, 480M
            |__ Port 2: Dev 11, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 2: Dev 11, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
            |__ Port 3: Dev 20, If 0, Class=Wireless, Driver=btusb, 12M
            |__ Port 3: Dev 20, If 1, Class=Wireless, Driver=btusb, 12M
            |__ Port 3: Dev 20, If 2, Class=Application Specific Interface, Driver=, 12M
            |__ Port 1: Dev 7, If 0, Class=Vendor Specific Class, Driver=lan78xx, 480M
        |__ Port 2: Dev 28, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 3: Dev 29, If 0, Class=Vendor Specific Class, Driver=, 1.5M

È possibile che non tutti i dispositivi abbiano i moduli corrispondenti associati. La comunicazione con alcuni dispositivi può essere gestita direttamente dall’applicazione, senza l’intermediazione fornita da un modulo. Tuttavia, ci sono informazioni significative nell’output fornito da lsusb -t. Quando esiste un modulo corrispondente, il suo nome appare alla fine della riga del dispositivo, come in Driver=btusb. Il dispositivo Class identifica la categoria generale, come per esempio Human Interface DeviceWirelessVendor Specific ClassMass Storage. Per verificare quale dispositivo stia utilizzando il modulo btusb, presente nell’elenco precedente, entrambi i numeri di Bus e Dev dovrebbero essere dati all’opzione -s del comando lsusb:

$ lsusb -s 01:20
Bus 001 Device 020: ID 1131:1001 Integrated System Solution Corp. KY-BT100 Bluetooth Adapter

È comune avere un ampio set di moduli kernel caricati, in qualsiasi momento, in un sistema Linux standard. Il modo preferibile per interagire con loro è usare i comandi forniti dal pacchetto kmod, che è un insieme di strumenti per gestire le attività comuni con i moduli del kernel Linux quali inserire, rimuovere, elencare, controllare le proprietà, risolvere dipendenze e alias. Il comando lsmod, per esempio, mostra tutti i moduli attualmente caricati:

$ lsmod
Module                  Size  Used by
kvm_intel             138528  0
kvm                   421021  1 kvm_intel
iTCO_wdt               13480  0
iTCO_vendor_support    13419  1 iTCO_wdt
snd_usb_audio         149112  2
snd_hda_codec_realtek  51465  1
snd_ice1712            75006  3
snd_hda_intel          44075  7
arc4                   12608  2
snd_cs8427             13978  1 snd_ice1712
snd_i2c                13828  2 snd_ice1712,snd_cs8427
snd_ice17xx_ak4xxx     13128  1 snd_ice1712
snd_ak4xxx_adda        18487  2 snd_ice1712,snd_ice17xx_ak4xxx
microcode              23527  0
snd_usbmidi_lib        24845  1 snd_usb_audio
gspca_pac7302          17481  0
gspca_main             36226  1 gspca_pac7302
videodev              132348  2 gspca_main,gspca_pac7302
rt61pci                32326  0
rt2x00pci              13083  1 rt61pci
media                  20840  1 videodev
rt2x00mmio             13322  1 rt61pci
hid_dr                 12776  0
snd_mpu401_uart        13992  1 snd_ice1712
rt2x00lib              67108  3 rt61pci,rt2x00pci,rt2x00mmio
snd_rawmidi            29394  2 snd_usbmidi_lib,snd_mpu401_uart

L’output del comando lsmod è diviso in tre colonne:Module

Nome del modulo. Size

Quantità di RAM occupata dal modulo, in byte. Used by

Moduli dipendenti.

Alcuni moduli richiedono altri moduli per funzionare correttamente, come nel caso dei moduli per dispositivi audio:

$ lsmod | fgrep -i snd_hda_intel
snd_hda_intel          42658  5
snd_hda_codec         155748  3 snd_hda_codec_hdmi,snd_hda_codec_via,snd_hda_intel
snd_pcm                81999  3 snd_hda_codec_hdmi,snd_hda_codec,snd_hda_intel
snd_page_alloc         13852  2 snd_pcm,snd_hda_intel
snd                    59132  19 snd_hwdep,snd_timer,snd_hda_codec_hdmi,snd_hda_codec_via,snd_pcm,snd_seq,snd_hda_codec,snd_hda_intel,snd_seq_device

La terza colonna, Used by, mostra i moduli che richiedono il modulo nella prima colonna per funzionare correttamente. Molti moduli dell’architettura audio di Linux, preceduti da snd, sono interdipendenti. Quando si cercano problemi durante la diagnostica del sistema, può essere utile scaricare i moduli specifici attualmente caricati. Il comando modprobe può essere usato sia per caricare sia per scaricare i moduli del kernel: per scaricare un modulo e i relativi moduli, purché non vengano utilizzati da un processo in esecuzione, dovrebbe essere usato il comando modprobe -r. Per esempio, per scaricare il modulo snd-hda-intel (il modulo per un dispositivo audio Intel HDA) e altri moduli relativi al sistema audio:

# modprobe -r snd-hda-intel

Oltre a caricare e scaricare i moduli del kernel mentre il sistema è in esecuzione, è possibile modificare i parametri del modulo durante il caricamento del kernel, in maniera non molto diversa dal passare opzioni ai comandi. Ogni modulo accetta parametri specifici, ma la maggior parte delle volte sono consigliati i valori predefiniti e non sono necessari parametri aggiuntivi. Tuttavia, in alcuni casi è necessario utilizzare i parametri per modificare il comportamento di un modulo affinché funzioni come previsto.

Usando il nome del modulo come unico argomento, il comando modinfo mostra una descrizione, il file, l’autore, la licenza, l’identificazione, le dipendenze e i parametri disponibili per il modulo dato. I parametri personalizzati per un modulo possono essere resi persistenti includendoli nel file /etc/modprobe.conf o in singoli file con l’estensione .conf nella directory /etc/modprobe.d/. L’opzione -p farà in modo che il comando modinfo visualizzi tutti i parametri disponibili e ignori le altre informazioni:

# modinfo -p nouveau
vram_pushbuf:Create DMA push buffers in VRAM (int)
tv_norm:Default TV norm.
                Supported: PAL, PAL-M, PAL-N, PAL-Nc, NTSC-M, NTSC-J,
                        hd480i, hd480p, hd576i, hd576p, hd720p, hd1080i.
                Default: PAL
                
NOTE Ignored for cards with external TV encoders. (charp)
nofbaccel:Disable fbcon acceleration (int)
fbcon_bpp:fbcon bits-per-pixel (default: auto) (int)
mst:Enable DisplayPort multi-stream (default: enabled) (int)
tv_disable:Disable TV-out detection (int)
ignorelid:Ignore ACPI lid status (int)
duallink:Allow dual-link TMDS (default: enabled) (int)
hdmimhz:Force a maximum HDMI pixel clock (in MHz) (int)
config:option string to pass to driver core (charp)
debug:debug string to pass to driver core (charp)
noaccel:disable kernel/abi16 acceleration (int)
modeset:enable driver (default: auto, 0 = disabled, 1 = enabled, 2 = headless) (int)
atomic:Expose atomic ioctl (default: disabled) (int)
runpm:disable (0), force enable (1), optimus only default (-1) (int)

L’output di esempio mostra tutti i parametri disponibili per il modulo nouveau, un modulo del kernel fornito dal Nouveau Project come alternativa ai driver proprietari per le schede GPU NVIDIA. L’opzione modeset, per esempio, permette di controllare se la risoluzione e la profondità del display saranno impostate nello spazio del kernel invece che nello spazio utente. L’aggiunta di options nouveau modeset = 0 al file /etc/modprobe.d/nouveau.conf disabiliterà la funzionalità modeset del kernel.

Se un modulo sta causando problemi:

il file /etc/modprobe.d/blacklist.conf può essere usatoper bloccare il caricamento del modulo. Per esempio, per impedire il caricamento automatico del modulo nouveau, la riga blacklist nouveau deve essere aggiunta al file /etc/modprobe.d/blacklist.conf. Questa azione è richiesta quando è installato il modulo proprietario nvidia e il modulo predefinito nouveau deve essere messo da parte.

I File Informativi e i File dei Dispositivi

I comandi lspcilsusb e lsmod fungono da front-end per leggere le informazioni hardware memorizzate dal sistema operativo. Questo tipo di informazioni è conservato in file speciali nelle directory /proc e /sys. Queste directory sono punti di montaggio per i filesystem non presenti in una partizione del dispositivo, ma solo nello spazio RAM utilizzato dal kernel per memorizzare la configurazione di runtime e le informazioni sui processi in esecuzione. Tali filesystem non sono destinati all’archiviazione convenzionale di file, quindi sono chiamati pseudo-filesystem e esistono solo mentre il sistema è in esecuzione. La directory /proc contiene file con informazioni relative ai processi in esecuzione e alle risorse hardware. Alcuni dei file importanti in /proc per l’ispezione dell’hardware sono:/proc/cpuinfo

Elenca informazioni dettagliate sulla/e CPU trovate dal sistema operativo./proc/interrupts

Un elenco degli interrupt per ogni periferica IO per ogni CPU./proc/ioports

Elenca le regioni di memoria attualmente in uso di porte input/output./proc/dma

Elenca i canali DMA (Direct Memory Access) in uso.

I file all’interno della directory /sys hanno ruoli simili a quelli in /proc. Tuttavia, la directory /sys ha lo scopo specifico di memorizzare informazioni sul dispositivo e dati del kernel relativi all’hardware, mentre /proc contiene anche informazioni su varie strutture di dati del kernel, inclusi i processi in esecuzione e la configurazione.

Un’altra directory direttamente correlata ai dispositivi in un sistema Linux standard è /dev. Ogni file all’interno di /dev è associato a un dispositivo di sistema, in particolare ai dispositivi di archiviazione. Un disco rigido IDE legacy, per esempio, quando è collegato al primo canale IDE della scheda madre è rappresentato dal file /dev/hda. Ogni partizione in questo disco sarà identificata da /dev/hda1/dev/hda2 e così via.

I dispositivi rimovibili sono gestiti dal sottosistema udev, che crea i dispositivi corrispondenti in /dev. Il kernel Linux acquisisce l’evento di rilevamento hardware e lo passa al processo udev, che quindi identifica il dispositivo e crea dinamicamente i file corrispondenti in /dev, usando regole predefinite.

Nelle attuali distribuzioni Linux udev è responsabile dell’identificazione e della configurazione dei dispositivi già presenti durante l’accensione della macchina (coldplug detect) e dei dispositivi identificati mentre il sistema è in esecuzione (hotplug detect). Udev si affida a SysFS, lo pseudo filesystem per le informazioni relative all’hardware montato in /sys.

Quando vengono rilevati nuovi dispositivi, udev cerca una regola corrispondente nelle regole predefinite memorizzate nella directory /etc/udev/rules.d/. Le regole più importanti sono fornite dalla distribuzione, ma è possibile aggiungerne di nuove per casi specifici.

I Dispositivi di Archiviazione

In Linux i dispositivi di archiviazione sono genericamente chiamati block device, poiché i dati vengono letti da e verso questi dispositivi in blocchi di dati bufferizzati con dimensioni e posizioni diverse. Ogni dispositivo a blocchi è identificato da un file nella directory /dev, con il nome del file a seconda del tipo di dispositivo (IDE, SATA, SCSI, ecc.) e delle sue partizioni. CD/DVD e dispositivi floppy, per esempio, avranno i loro nomi indicati di conseguenza in /dev: un’unità CD/DVD collegata al secondo canale IDE verrà identificata come /dev/hdc (/dev/hda e /dev/hdb sono riservati per i dispositivi master e slave sul primo canale IDE) e una vecchia unità floppy verrà identificata come /dev/fd0/dev/fd1, ecc..

A partire dalla versione 2.4 del kernel Linux, la maggior parte dei dispositivi di archiviazione viene ora identificata come se fossero dispositivi SCSI, indipendentemente dal tipo di hardware. I dispositivi di blocco IDE, SSD e USB saranno preceduti da sd. Per i dischi IDE, verrà usato il prefisso sd, ma verrà scelta la terza lettera a seconda che il drive sia un master o uno slave (nel primo canale IDE, il master sarà sda e lo slave sarà sdb ). Le partizioni sono elencate numericamente. I percorsi /dev/sda1/dev/sda2, ecc. sono usati per la prima e la seconda partizione del dispositivo a blocchi identificati per primi e /dev/sdb1/dev/sdb2, ecc. usati per identificare la prima e la seconda partizione del dispositivo a blocchi identificato per secondo. L’eccezione a questo modello si verifica con schede di memoria (schede SD) e dispositivi NVMe (SSD collegato al bus PCI Express). Per le schede SD, i percorsi /dev/mmcblk0p1/dev/mmcblk0p2, ecc. vengono utilizzati per la prima e la seconda partizione del dispositivo identificate per prime e /dev/mmcblk1p1/dev/mmcblk1p2, ecc. usato per identificare la prima e la seconda partizione del dispositivo identificato per secondo. I dispositivi NVMe ricevono il prefisso nvme, come in /dev/nvme0n1p1 e /dev/nvme0n1p2.

/ 5
Grazie per aver votato!

How useful was this post?

Click on a star to rate it!

Average rating / 5. Vote count:

No votes so far! Be the first to rate this post.

As you found this post useful...

Follow us on social media!

We are sorry that this post was not useful for you!

Let us improve this post!

Tell us how we can improve this post?