A la lliçó anterior vam tractar el disc com si fos el dispositiu del sistema. Però meteo-01 té molt més: dos SSD NVMe, un disc mecànic, una targeta de xarxa, un rellotge de temps real, un terminal sèrie, un generador de nombres aleatoris i uns quants controladors USB. I les estacions meteorològiques que li envien dades tenen sensors, rellotges i ràdios. Cap d'aquests dispositius s'assembla als altres: difereixen en velocitat per un factor d'un milió, en unitat de transferència, en si es poden llegir, escriure o totes dues coses, i en si responen en microsegons o en minuts.

El sistema operatiu ha d'oferir una interfície coherent per a tots ells sense conèixer els detalls de cap. Aquesta lliçó tracta de com ho aconsegueix: quina classificació fa servir, per què a UNIX «tot és un fitxer», com apareixen els fitxers a /dev, i quines són les tres maneres que té la CPU de parlar amb un dispositiu. Acabarem seguint el camí d'una lectura d'estació des de la targeta de xarxa fins a la memòria intermèdia de l'ingestor, i deixarem el mecanisme intern de les interrupcions per a la lliçó següent, que el desenvolupa en detall.

1. Per què el sistema operatiu uniformitza els dispositius
2. L'estructura del subsistema d'E/S
3. Classificació: bloc, caràcter i xarxa
4. «Tot és un fitxer» i el directori /dev
5. Números major i menor
6. udev i la creació dinàmica de dispositius
7. Busos i enumeració: lspci, lsusb, lsblk
8. Les tres maneres de parlar amb un dispositiu
9. Ports d'E/S i E/S mapejada en memòria
10. Tècniques del subsistema: buffering, caching, spooling i reserva
11. Tractament d'errors i reintents
12. El camí d'una lectura d'estació

Mira la varietat real a què s'enfronta el nucli de meteo-01:

Entre el teclat i la GPU hi ha nou ordres de magnitud de diferència en velocitat. I tanmateix, el programador de l'ingestor escriu:

i aquesta mateixa línia funciona si fd és un socket de xarxa, un fitxer a l'SSD, un terminal o el generador d'aleatoris. Aquesta uniformitat no és comoditat: és el que fa possible escriure programari.

Sense ella, cada programa hauria de conèixer el model exacte de cada dispositiu. Un canvi de targeta de xarxa obligaria a recompilar totes les aplicacions. És exactament el problema que el sistema operatiu com a màquina estesa resol, i que vam plantejar a 01-01.

Els objectius concrets del subsistema d'E/S són cinc:

El subsistema s'organitza en capes, cadascuna afegint abstracció sobre l'anterior:

El repartiment de responsabilitats:

El punt clau és a la capa independent del dispositiu: és la que fa tota la feina comuna una sola vegada, perquè cada controlador només hagi d'implementar allò veritablement específic. Un controlador de xarxa no ha de saber res de permisos, ni de noms, ni de buffering: només com parlar amb el seu xip.

I aquí connecta amb la lliçó 01-05: els controladors viuen dins del nucli en un sistema monolític com Linux, carregats com a mòduls. Per això un e1000e defectuós pot tombar la màquina sencera, mentre que en un microkernel viuria a l'espai d'usuari a canvi de més IPC.

Linux classifica els dispositius en tres grans famílies, i aquesta classificació determina quina interfície ofereix cadascun:

Dispositius de bloc. La lliçó anterior en va tractar la gestió completa: matriu de blocs numerats per LBA, planificació de peticions, memòria cau. La característica que els defineix és l'accés aleatori: pots llegir el bloc 5.000 sense haver llegit els 4.999 anteriors.

Dispositius de caràcter. Són un flux: els bytes van arribant i no pots retrocedir. Un teclat, un port sèrie, un generador d'aleatoris. No té sentit «buscar la posició 500» en un teclat.

La c inicial indica character device. Fixa't que /dev/null i /dev/zero no corresponen a cap maquinari: són dispositius virtuals implementats enterament en programari. /dev/null descarta tot el que se li escriu; /dev/zero produeix zeros infinits. Que existeixin demostra que l'abstracció de dispositiu és prou general per embolcallar coses que no són dispositius.

Dispositius de xarxa. Són l'excepció interessant: no tenen fitxer a /dev.

La raó és de fons: un fitxer implica un flux de bytes ordenat i sense pèrdues, i la xarxa no és això. Els paquets es poden perdre, duplicar o arribar desordenats, i cadascun porta metadades (adreces, ports, protocol) que no encaixen a read()/write(). Per això UNIX va inventar una abstracció diferent —el socket, amb socket(), bind(), sendto(), recvfrom()— per a allò que no cabia en la de fitxer.

És una lliçó de disseny valuosa: una bona abstracció té límits, i forçar-la més enllà produeix interfícies pitjors. Els creadors de BSD ho van reconèixer i van crear una segona abstracció en lloc de deformar la primera.

Tot i així, un cop obert, un socket sí que es maneja amb un descriptor de fitxer i admet read() i write(). L'abstracció de fitxer cobreix l'ús; només la creació i la configuració necessiten interfície pròpia.

El principi que defineix UNIX: els dispositius es presenten com a fitxers especials dins del sistema de fitxers.

Les conseqüències són enormes i molt pràctiques:

Tres avantatges concrets d'això:

1. Un sol model de permisos. Que /dev/nvme0n1 pertanyi al grup disk amb permisos rw-rw---- és el que impedeix que l'usuari meteora llegeixi el disc cru saltant-se els permisos del sistema de fitxers. Sense el model de fitxers caldria un sistema de permisos a part per als dispositius.
2. Reutilització d'eines. cat, dd, cp, grep funcionen sobre dispositius sense haver estat programats per fer-ho.
3. Composició. Pots redirigir, canalitzar i encadenar dispositius com qualsevol altra cosa.

Un exemple que aprofita les tres alhora:

Copia un dispositiu de bloc sencer, el comprimeix al vol i el desa. dd no sap res d'NVMe, gzip no sap res de dispositius, i cap dels dos no ho ha hagut de saber.

I l'operador > de la shell aprofita justament el que vam veure a 02-01: la shell fa fork, al fill obre el fitxer com a descriptor 1, i després execve. El programa nou escriu al descriptor 1 sense assabentar-se de res.

Un fitxer de dispositiu no conté dades: conté una referència a un controlador. Aquesta referència són dos números.

Analitzem la línia de /dev/sda camp a camp:

On un fitxer normal mostraria la seva mida en bytes, un fitxer de dispositiu mostra dos números separats per una coma. Aquest és el detall que delata que no és un fitxer corrent.

Exemples que aclareixen la mecànica:

Tots tenen major 8 (el controlador de discos SCSI/SATA), i el menor els distingeix: 0 és el disc sda sencer, 1 i 2 les seves particions, 16 és el disc següent. La convenció assigna 16 menors per disc, cosa que permet 15 particions a cadascun.

Els majors estan registrats oficialment:

Quan obres /dev/sda, el nucli llegeix el major (8), busca en aquesta taula quin controlador l'ha registrat, i li passa l'operació juntament amb el menor perquè sàpiga a quin disc es refereix. Aquest és tot el mecanisme de despatx d'E/S.

Pots crear fitxers de dispositiu a mà, encara que avui gairebé mai no calgui:

Prova conceptualment reveladora: /dev/eldisc amb major 8 i menor 0 és exactament /dev/sda. El nom no significa res; l'única cosa que importa són els dos números. Els noms són una convenció humana.

Antigament /dev era un directori normal amb milers de fitxers creats per endavant per si de cas. Era un desastre: no se sabia quins corresponien a maquinari present, i connectar alguna cosa nova exigia crear el fitxer a mà.

Avui /dev és un sistema de fitxers virtual (devtmpfs) que reflecteix el maquinari realment present, gestionat per udev.

Quan es connecta un dispositiu, la seqüència és:

Observar-ho en directe és la millor manera d'entendre-ho:

I consultar tot el que udev sap d'un dispositiu concret:

Les línies S: són enllaços simbòlics alternatius, i resolen un problema molt real: el nom nvme0n1 depèn de l'ordre de detecció, que pot canviar entre arrencades. Els enllaços per identificador de sèrie no canvien mai.

Per això /etc/fstab ha de fer servir UUID o /dev/disk/by-id/, mai /dev/sda1. Si afegeixes un disc i l'ordre canvia, un fstab amb noms directes pot muntar el volum equivocat. Ho veurem aplicat a Particions, Muntatge i Sistema de Fitxers Virtual.

Pots definir les teves pròpies regles. Un cas real de Meteora: una de les estacions es connecta per USB-sèrie al servidor per a diagnòstic, i vols que aparegui sempre amb el mateix nom i accessible per l'usuari meteora.

Com funciona cada part:

• SUBSYSTEM=="tty": només s'aplica a dispositius de terminal sèrie.
• ATTRS{idVendor}/ATTRS{idProduct}: identifiquen el xip FTDI concret.
• ATTRS{serial}: distingeix aquesta estació d'una altra amb el mateix xip. Sense això, dos adaptadors idèntics coincidirien amb la regla.
• SYMLINK+=: crea /dev/meteora/estacio-nord, un nom estable i independent de si el nucli l'ha anomenada ttyUSB0 o ttyUSB3.
• OWNER/GROUP/MODE: fan el dispositiu accessible a l'usuari meteora sense necessitat de root.

Aquest darrer punt és important des del punt de vista de la seguretat: en lloc d'executar el procés de diagnòstic com a root perquè pugui obrir el port sèrie, se li donen permisos exactes sobre aquest dispositiu concret. És el principi de mínim privilegi, que desenvoluparem a Principis de Protecció i Control d'Accés.

Una altra regla útil: fixar el planificador d'E/S per tipus de dispositiu, reprenent el de la lliçó anterior.

Així el planificador correcte s'aplica automàticament a cada arrencada i a cada disc que es connecti, segons si és rotacional o no.

Els dispositius es connecten a través de busos, i cada bus té el seu propi mecanisme d'enumeració: la manera com el sistema descobreix què hi ha connectat.

L'identificador 03:00.0 segueix el format bus:dispositiu.funció, i és l'adreça física de la targeta a la topologia PCI. La versió detallada revela com hi parla el nucli:

Cada línia diu alguna cosa que farem servir:

• bus master: la targeta pot iniciar transferències DMA pel seu compte, sense que la CPU copiï les dades.
• IRQ 128: la línia d'interrupció assignada. Apareixerà a /proc/interrupts.
• Memory at df200000 [size=128K]: els seus registres estan mapejats en memòria en aquesta adreça física.
• I/O ports at e000: a més té ports d'E/S clàssics.
• MSI-X: Enable+ Count=5: fa servir interrupcions senyalitzades per missatge, amb 5 vectors diferents.
• Kernel driver in use: igb: quin mòdul la gestiona.

Aquesta darrera línia és la primera comprovació quan un dispositiu no funciona: si no apareix, no hi ha driver carregat i el maquinari és present però inert. És exactament l'escenari que vam veure a 01-05 amb lsmod i modinfo.

lsusb -t mostra l'arbre amb el driver de cada node (ftdi_sio per a l'estació) i la velocitat negociada (12 Mb/s, USB 1.1 completa, suficient per a un port sèrie).

I el mapa complet de dispositius de bloc, que vam veure a la lliçó anterior:

Quan la CPU necessita transferir dades amb un dispositiu, hi ha tres mecanismes possibles. Aquest apartat els contrasta; el mecanisme intern de les interrupcions i del DMA és el tema de la lliçó següent, aquí només interessa quan es fa servir cadascun i quant costa.

La CPU consulta repetidament un registre d'estat del dispositiu fins que indica que està llest, i llavors transfereix les dades ella mateixa, byte a byte o paraula a paraula.

• Avantatge: latència mínima i simplicitat total. Sense interrupcions ni sincronització.
• Inconvenient: la CPU no fa res més mentre espera.

Amb un dispositiu lent el malbaratament és catastròfic:

Trenta milions de cicles per lletra. Tot i així, l'espera activa continua sent l'opció correcta en tres casos: quan el dispositiu respon en menys temps del que costaria una interrupció (uns pocs microsegons), durant l'arrencada —quan el sistema d'interrupcions encara no està configurat—, i en un gestor de pànic, quan ja no es pot confiar en res més.

La CPU inicia l'operació i se n'oblida: adorm el procés i en planifica un altre. Quan el dispositiu acaba, envia una interrupció i el nucli desperta el procés.

Reconeixeràs cada pas: són exactament les transicions del diagrama d'estats de 02-01. Els estats S i D existeixen precisament per això.

• Avantatge: la CPU s'aprofita durant l'espera.
• Inconvenient: cada interrupció costa entre 1 i 5 µs, i la CPU continua copiant les dades byte a byte.

I aquí hi ha el problema que queda per resoldre: amb una targeta de xarxa a 1 Gb/s rebent paquets de 1.500 bytes:

Un quart de nucli només per atendre interrupcions, sense comptar la còpia de les dades.

El DMA és una controladora que transfereix dades entre el dispositiu i la memòria sense intervenció de la CPU. La CPU només programa l'operació (adreça de destinació, mida) i rep una única interrupció al final.

Transferir 1 MB des d'un dispositiu:

Amb números concrets per a 1 MB des de l'SSD:

Un factor de més de 150 respecte de l'E/S per interrupcions. Per això tot dispositiu que mogui volum fa servir DMA: discos, xarxa, GPU, so. El bus master que vèiem a lspci és precisament la capacitat de fer-ho.

Regla de decisió resumida:

Queda una pregunta: com s'accedeix físicament als registres d'un dispositiu. Hi ha dos enfocaments.

x86 té un espai d'adreces a part, de 65.536 ports, amb instruccions dedicades:

Recordaràs in i out de la taula d'instruccions privilegiades de 01-06: només es poden executar en mode nucli. Aquest és el mecanisme que impedeix que un programa d'usuari parli directament amb el maquinari.

Aquí hi ha els ports històrics: 0x60 i 0x64 per al teclat, 0x3F8 per a COM1, 0x70 per al rellotge de temps real. Números que no canvien des de l'IBM PC de 1981.

Els registres del dispositiu s'assignen a adreces de l'espai de memòria física. Llegir-hi o escriure-hi és accedir al dispositiu.

Els 128 KB a 0xdf200000 són els registres de la targeta de xarxa que vam veure a lspci. El driver igb els ha reservat i hi accedeix amb instruccions normals de memòria.

Comparació dels dos enfocaments:

MMIO ha guanyat, i per una raó que ara entens perfectament: com que viu a l'espai d'adreces normal, la protecció l'aplica la MMU amb la granularitat de pàgina que vam estudiar a 02-04. Es pot donar a un procés accés als registres d'un dispositiu concret sense donar-li accés a res més. Amb ports d'E/S la protecció és de tot o res.

A més, MMIO permet que un driver accedeixi als registres amb codi C normal, sense assemblador, cosa que fa el codi portable entre arquitectures.

Un detall crític: les pàgines de MMIO s'han de marcar com a no emmagatzemables a la memòria cau (bit PCD de la taula de pàgines, que vam veure a 02-04). Si la CPU desés a la memòria cau un registre d'estat del dispositiu, en llegiria un valor obsolet en lloc de l'estat real del maquinari, i el driver es penjaria esperant una condició que ja s'ha complert. És un exemple perfecte de com dos mecanismes correctes per separat —memòria cau i MMIO— es destrueixen mútuament si no es coordinen.

La capa independent del dispositiu aplica quatre tècniques generals. Totes resolen un desajust diferent.

Una memòria intermèdia és una àrea de memòria entre el productor i el consumidor. Resol tres problemes diferents:

Ja en vam calcular l'impacte a 01-06: agrupar 170 lectures abans d'escriure reduïa les crides al sistema en un factor de 167.

Per què la doble memòria intermèdia. Amb una sola memòria intermèdia apareix un problema de bloqueig:

Mentre el procés processa la memòria intermèdia, el dispositiu no hi pot escriure i ha d'esperar. I a l'inrevés. Les dues parts se serialitzen.

Mentre el dispositiu omple la memòria A, el procés processa la B. En acabar, s'intercanvien. El rendiment passa d'1/(t_omplir + t_processar) a 1/max(t_omplir, t_processar).

Càlcul per a l'ingestor:

La generalització és la memòria intermèdia circular amb N posicions, que és el que fan servir les cues de sockets i les cues de descriptors de les targetes de xarxa modernes.

Una memòria intermèdia i una memòria cau es confonen sovint, però són coses diferents:

La memòria cau de pàgines de Linux és la memòria cau de disc del sistema, i és la que vèiem com a buff/cache a free -h:

Aquests 4,3 GB són contingut de fitxers mantingut a la RAM. Quan l'agregador llegeix 2026-08-31.dat per segona vegada, no toca el disc: les dades ja hi són. És la mateixa memòria cau que dona suport a les pàgines de mmap() que vam fer servir a 02-04.

Comprovar-ho és senzill i molt il·lustratiu:

20 vegades més ràpid la segona vegada, sense haver tocat el disc. Aquest factor de 20 és el que la memòria cau de pàgines aporta contínuament i de manera invisible.

Spool ve de Simultaneous Peripheral Operation On-Line. És la tècnica per a dispositius que no es poden compartir intercalant operacions.

Si dos processos escriuen simultàniament en una impressora sense coordinació, la sortida surt barrejada línia a línia. El spooling ho resol: cada treball s'escriu sencer en un directori de cua, i un dimoni els imprimeix un a un, en ordre.

L'interessant és que el spooling continua molt viu encara que les impressores ja no importin: cron, el correu i les cues de missatgeria fan servir el mateix patró. La idea general —encuar treballs en emmagatzematge persistent i processar-los seqüencialment amb un únic consumidor— és un dels patrons més reutilitzats de la informàtica.

A Meteora, l'enviament nocturn de la còpia de seguretat al servidor remot funciona així: els fitxers es deixen en un directori de sortida i un procés els transfereix d'un en un, reintentant els que fallen.

Alguns dispositius s'han de fer servir en exclusiva. El sistema ofereix mecanismes per reservar-los:

flock amb LOCK_EX | LOCK_NB intenta un bloqueig exclusiu sense esperar: si un altre procés ja té el port, falla immediatament en lloc de quedar-se penjat.

La reserva exclusiva introdueix el risc d'interbloqueig: si el procés A té el port sèrie i espera el mòdem, i B té el mòdem i espera el port sèrie, cap dels dos no avança. Aquest problema té lliçó pròpia: Interbloquejos.

El principi general: els errors es tracten com més a prop del maquinari millor, i només pugen si no es poden resoldre a baix.

Un exemple real de la cadena completa, vist des del registre del nucli:

Traducció de la traça:

• UNC (uncorrectable): el disc no ha pogut llegir un sector ni tan sols amb la seva correcció d'errors interna.
• El controlador va reintentar diverses vegades (d'aquí els 3 segons entre la primera i l'última línia).
• En esgotar els reintents, va generar un Medium Error.
• El sistema de fitxers el rep com a EIO, i el procés que ha fet read() obté -1 amb errno = EIO.

Aquest errno és exactament el mecanisme que vam rastrejar fins al seu origen a 01-06: un valor negatiu retornat pel nucli que la libc converteix en -1 més errno.

Categories d'error i què fer amb cadascuna:

EINTR mereix insistència perquè és la font d'errors més traïdora. Ja el vam veure a l'exemple de buffering de 01-06: si arriba un senyal mentre el procés està bloquejat a read() o write(), la crida retorna amb EINTR sense haver fet res. No és un error: cal reintentar. Ignorar-ho produeix pèrdues de dades esporàdiques i irreproduïbles.

Quatre línies que eviten tota una classe de fallades intermitents.

Tanquem aplicant-ho tot a un recorregut concret: una estació meteorològica envia una lectura de 24 bytes i l'ingestor la rep. Aquí veiem quines capes hi intervenen i què fa cadascuna; el mecanisme intern de la interrupció i del DMA és el contingut de la lliçó següent.

Recorregut amb el paper de cada capa:

Fixa't en la divisió de feina. Els passos 1-6 són específics d'aquesta targeta: només el driver igb sap com llegir-ne els registres. A partir del pas 7 el codi és comú a totes les targetes de xarxa del món: la pila IP/UDP no sap ni li importa quin maquinari ha portat el paquet. Aquesta frontera és exactament la que vam dibuixar al diagrama de capes de l'apartat 2, i és la que permet que Linux admeti centenars de targetes diferents amb una sola pila de xarxa.

I observa una cosa més: l'ingestor no ha participat en res d'això. Estava adormit en estat S des del seu read(). Tota la feina l'han feta el maquinari, el DMA, el gestor d'interrupció i la pila de xarxa. El procés només es desperta quan ja hi ha dades esperant-lo.

Un càlcul de cost que motiva la lliçó següent. Amb 800 lectures/segon:

Aquest és el problema de la tempesta d'interrupcions, i la seva solució —que el sistema deixi de fer servir interrupcions i passi a consultar activament quan la càrrega és alta— és un dels mecanismes més elegants del nucli de Linux. Es diu NAPI i el veurem en detall tot seguit.

Fer servir /dev/sda1 a /etc/fstab. El nom depèn de l'ordre de detecció i pot canviar en afegir maquinari. Fes servir sempre UUID= o /dev/disk/by-id/. El dia que afegeixis un disc i el sistema no arrenqui, entendràs per què.

Confondre memòria intermèdia i memòria cau. Una memòria intermèdia conté l'única còpia de dades en trànsit; perdre-la vol dir perdre dades. Una memòria cau conté una còpia d'alguna cosa que existeix en un altre lloc; perdre-la només costa rendiment. drop_caches buida memòries cau, mai memòries intermèdies amb dades pendents.

Executar com a root per accedir a un dispositiu. Gairebé sempre la solució correcta és una regla d'udev que doni permisos exactes sobre aquest dispositiu concret a l'usuari que el necessita. Root per llegir un port sèrie és donar mil permisos per fer-ne servir un.

Ignorar EINTR. És la causa més freqüent de fallades intermitents en codi d'E/S. Qualsevol read, write o close sobre un descriptor bloquejant ho ha de contemplar.

Creure que un dispositiu de xarxa hauria de tenir fitxer a /dev. No en té, i és una decisió de disseny conscient: els paquets no són un flux de bytes fiable i ordenat. L'abstracció correcta és el socket.

Interpretar malament lspci quan alguna cosa no funciona. Si el dispositiu apareix però no hi ha línia Kernel driver in use, el maquinari és present i sense driver. Si no apareix en absolut, és un problema físic o de BIOS. Són dos diagnòstics completament diferents.

Consell de diagnòstic: quan un dispositiu no funciona, l'ordre que funciona és: lspci/lsusb (el veu, el sistema?), lspci -v | grep -i driver (té driver?), dmesg -T | tail -50 (què ha dit el nucli en detectar-lo?), ls -l /dev/... (existeix el node i amb quins permisos?), i udevadm info --query=all --name=... (què en sap, udev?). Cinc comprovacions que localitzen el problema a la capa exacta.

Donada aquesta sortida:

1. Classifica cada entrada per tipus i explica com ho saps.
2. Per què /dev/sda i /dev/sda1 comparteixen el major però no el menor?
3. Si l'usuari meteora (grup meteora) executa dd if=/dev/sda of=/tmp/copia bs=1M count=10, funciona? I sobre /dev/meteora/estacio-nord?
4. Què representa el 7 de l'última línia, on les altres tenen dos números?
5. Escriu una regla d'udev que doni al grup meteora accés de només lectura a /dev/sda, i explica si és bona idea.

Per a cadascun d'aquests dispositius de Meteora, decideix quina tècnica d'E/S és l'adequada (espera activa, interrupcions o DMA) i justifica-ho amb un càlcul:

• A: Sensor I²C d'una estació, que retorna 2 bytes en 8 µs després de la petició. Es consulta una vegada per minut. El microcontrolador va a 80 MHz.
• B: Targeta de xarxa de meteo-01 rebent 800 lectures/segon de 24 bytes en paquets UDP de 66 bytes.
• C: SSD NVMe llegint els 17 MB de 2026-08-31.dat.
• D: Adaptador USB-sèrie de diagnòstic a 9.600 bauds, que envia 200 caràcters cada vegada que es connecta.

Per a cadascun indica la tècnica, el càlcul del cost de CPU i què passaria si triessis malament.

Has connectat una segona targeta de xarxa a meteo-01 per separar el trànsit de les estacions del trànsit de l'API, però no apareix com a interfície. Dissenya el procediment de diagnòstic complet:

1. Escriu la seqüència d'ordres que executaries, en ordre, i què hi busques a cadascuna.
2. Per a cadascun d'aquests quatre resultats possibles, digues què conclous i què faries:
   • a) lspci no mostra cap targeta nova.
   • b) lspci la mostra però sense línia Kernel driver in use.
   • c) lspci la mostra amb driver, ip link la mostra com a enp5s0 en estat DOWN.
   • d) dmesg mostra igb 0000:05:00.0: Failed to initialize MSI-X interrupts.
3. Un cop funcionant, escriu una regla d'udev que li doni un nom estable estacions0 i explica per què no n'hi ha prou amb ip link set name.

Solució 1

1. Classificació.

El senyal més fiable és la columna on un fitxer normal posaria la mida: si hi ha dos números separats per una coma, és un fitxer de dispositiu.

2. Mateix major, menor diferent.

El major 8 identifica el controlador (sd, discos SCSI/SATA). Tots dos els gestiona el mateix driver, així que comparteixen major.

El menor identifica quina instància concreta dins d'aquest driver:

Una partició no és un dispositiu diferent: és una finestra sobre un rang de blocs del mateix disc físic. El driver sd rep el menor, consulta la seva taula de particions i aplica el desplaçament corresponent.

La convenció assigna 16 menors per disc: menors 0-15 per a sda i les seves 15 particions, 16-31 per a sdb, i així successivament. Per això /dev/sdb té menor 16.

3. Permisos de l'usuari meteora.

Sobre /dev/sda: NO funciona.

• Propietari root, amb rw. meteora no és root.
• Grup disk, amb rw. Caldria comprovar si meteora pertany a disk:

No hi pertany.

• Altres: ---, sense cap permís.

Resultat: dd: failed to open '/dev/sda': Permís denegat.

I està bé que sigui així. Accés de lectura al disc cru significa poder llegir qualsevol fitxer del sistema saltant-se completament els permisos del sistema de fitxers: /etc/shadow inclòs. Equival a ser root per a lectura.

Sobre /dev/meteora/estacio-nord: SÍ que funciona, si la regla d'udev de la lliçó està activa.

L'enllaç apunta a ttyUSB0, i els permisos que compten són els del destí, no els de l'enllaç (els lrwxrwxrwx d'un enllaç simbòlic són sempre així i no volen dir res). Amb la regla:

Propietari meteora amb rw: accés concedit. Tot i que dd sobre un port sèrie llegiria el flux entrant, no un contingut amb estructura.

4. El número 7 de l'enllaç simbòlic.

És la mida en bytes de l'enllaç, és a dir, la longitud de la cadena que conté:

Un enllaç simbòlic sí que és un fitxer de veritat: el seu contingut és la ruta de destinació. Per això mostra una mida on els fitxers de dispositiu mostren major i menor. Els dispositius reals no mostren mida perquè no contenen res: només referencien un driver.

Comprovació:

5. Regla d'udev per donar lectura de /dev/sda al grup meteora.

Resultat: brw-r----- 1 root meteora 8, 0 /dev/sda.

És bona idea? Rotundament no.

El raonament:

1. Elude completament els permisos del sistema de fitxers. Llegint el dispositiu cru s'accedeix als bytes de tots els fitxers d'aquest disc, inclosos /etc/shadow i les claus privades de TLS. Els permisos de fitxer s'apliquen a través del sistema de fitxers; l'accés al dispositiu se'ls salta.

2. Viola el principi de mínim privilegi. Si l'agregador necessita llegir dades, necessita llegir fitxers de /var/lib/meteora/lectures/, no el disc sencer. El permís concedit és uns quants ordres de magnitud més gran que la necessitat.

3. Amplia enormement la superfície d'atac. Si algú compromet un procés que corre com a meteora, obté lectura completa del disc.

4. No hi ha cap cas legítim a Meteora que ho requereixi. Els usos reals del disc cru —clonatge, anàlisi forense, recuperació— són tasques administratives puntuals, no operacions d'un servei.

Alternativa correcta segons el que es necessiti:

Això concedeix exactament una ordre amb exactament uns arguments, en lloc d'accés complet al disc. És la diferència entre una clau d'una porta i una clau mestra de l'edifici.

Solució 2

A: Sensor I²C, 2 bytes en 8 µs, una vegada per minut, microcontrolador a 80 MHz.

Tècnica: espera activa.

Justificació:

• 640 cicles és menys del que costaria una interrupció. Configurar el vector, desar el context, executar el gestor i restaurar costa de l'ordre de 200-500 cicles en un microcontrolador, més la complexitat del codi. La interrupció seria més cara que l'espera.
• És un microcontrolador amb FreeRTOS, com vam establir a 01-03. No hi ha multitasca pesada competint: no hi ha res millor a fer durant aquests 8 µs.
• La simplicitat té valor propi en sistemes encastats: menys codi, menys estat, menys maneres de fallar.

Si triessis malament (interrupcions): funcionaria, però amb més codi, més complexitat i més consum de CPU que la mateixa espera. Un cas rar on la solució «avançada» és objectivament pitjor.

B: Targeta de xarxa, 800 lectures/s en paquets UDP de 66 bytes.

Tècnica: DMA amb interrupcions (i moderació d'interrupcions).

Observació honesta: amb només 800 paquets/s, el DMA i les interrupcions pures donen un cost gairebé idèntic, perquè el cost està dominat per la interrupció, no per copiar 66 bytes. El DMA guanya clarament quan els paquets són grans o abundants.

Però hi ha dues raons sòlides per fer servir DMA igualment:

1. Escalabilitat. Si Meteora creix fins a 500.000 lectures/s, sense DMA la còpia sola consumiria un nucli sencer.
2. No és opcional. Les targetes modernes només funcionen per DMA: el driver igb programa descriptors i la targeta escriu directament a la RAM. L'E/S programada ja no existeix en aquest maquinari.

Si triessis malament (espera activa): un nucli sencer consultant el registre de la targeta permanentment, per rebre 52,8 KB/s. Absurd.

C: SSD NVMe llegint 17 MB.

Tècnica: DMA, sense cap dubte.

I a més hi ha un argument qualitatiu encara més fort:

Amb espera activa, la CPU estaria bloquejada 4,9 ms sense fer res. A 3 GHz són gairebé 15 milions de cicles perduts, i equival a més d'un quantum sencer del planificador (4 ms, segons 02-02). Amb DMA, aquests 4,9 ms els aprofita un altre procés.

Si triessis malament: a més del malbaratament, el procés no es podria bloquejar en estat S, i es trencaria tot el model de planificació que vam estudiar a 02-02.

D: USB-sèrie a 9.600 bauds, 200 caràcters en connectar.

Tècnica: interrupcions (que és el que fa el driver ftdi_sio).

Justificació: 1,04 ms per caràcter és una eternitat per a una CPU. És exactament l'escenari per al qual es van inventar les interrupcions: dispositiu lentíssim, dades escasses, esperes llarguíssimes.

Detall interessant: USB no genera una interrupció per byte. La controladora USB agrupa les transferències en paquets i el xip FTDI té la seva pròpia memòria intermèdia, així que 200 caràcters poden arribar en 3 o 4 transferències. És buffering aplicat al mateix maquinari, exactament per les raons de l'apartat 10.

Si triessis malament (espera activa): 208 ms de CPU bloquejada. A meteo-01, amb l'ingestor rebent 800 lectures/s, aquests 208 ms significarien 166 lectures sense atendre. Un port sèrie de diagnòstic hauria degradat el servei de producció.

Resum:

La regla que n'emergeix: espera activa quan l'espera és més curta que la interrupció; DMA quan hi ha volum; interrupcions en tota la resta.

Solució 3

1. Seqüència de diagnòstic.

La lògica de l'ordre és anar de baix a dalt: maquinari → driver → nucli → interfície. No té sentit investigar la configuració de xarxa si el bus PCI ni tan sols veu la targeta.

2. Els quatre escenaris.

a) lspci no mostra cap targeta nova.

Conclusió: el problema és per sota del sistema operatiu. Linux no pot gestionar maquinari que el bus PCI no enumera; no és un problema de drivers ni de configuració.

Causes possibles i què fer:

El reescaneig és útil perquè descarta el cas d'una targeta inserida en calent que no va ser detectada. Si després d'això continua sense aparèixer, el problema és físic o de BIOS.

b) Apareix a lspci però sense Kernel driver in use.

Conclusió: el maquinari és present i correctament enumerat, però no hi ha driver que el gestioni. La targeta existeix i està inerta.

Si apareix Kernel modules: igb, el nucli sap quin mòdul la gestionaria però no l'ha carregat.

Si el mòdul és a la llista negra, apareixerà a /etc/modprobe.d/:

Aquest és l'escenari del driver e1000e defectuós que vam veure a 01-05: maquinari present, mòdul absent o bloquejat.

c) Apareix amb driver, ip link la mostra com a enp5s0 en estat DOWN.

Conclusió: tot el subsistema de dispositius funciona correctament. El driver està carregat, el nucli ha creat la interfície, udev l'ha anomenada. El que falta és configuració de xarxa o enllaç físic.

Link detected és la comprovació decisiva en aquest escenari: separa un problema de cablatge d'un de configuració, que són dues investigacions completament diferents.

Per fer-ho persistent:

d) dmesg mostra Failed to initialize MSI-X interrupts.

Conclusió: el driver s'ha carregat però no ha pogut configurar les interrupcions, que com vam veure a lspci són MSI-X amb 5 vectors. Sense interrupcions funcionant, la targeta no pot avisar que ha rebut paquets.

Si diu Falling back to MSI interrupts, el driver ha degradat a MSI i probablement funcioni, encara que amb menys paral·lelisme: en lloc de 5 vectors (un per cua), en tindrà un de sol, cosa que redueix el rendiment amb càrrega alta.

Causes i solucions:

Si funciona degradada a MSI, és acceptable per a Meteora amb 800 lectures/s —ja hem calculat que són 2,4 ms/s de CPU—, però convé resoldre-ho per tenir marge de creixement. El detall d'MSI, MSI-X i per què importen diversos vectors és el contingut de la lliçó següent.

3. Regla d'udev per a un nom estable.

Explicació de cada condició:

• SUBSYSTEM=="net": només interfícies de xarxa.
• ACTION=="add": només en aparèixer el dispositiu.
• ATTR{address}: l'adreça MAC, que és única i immutable al maquinari. És el que garanteix que la regla identifiqui aquesta targeta i no una altra.
• ATTR{type}=="1": tipus Ethernet, per no coincidir amb interfícies virtuals.
• NAME=: el nom definitiu. Compte: per a interfícies de xarxa es fa servir NAME, no SYMLINK, perquè la interfície es reanomena en lloc de crear un àlies.

Per què no n'hi ha prou amb ip link set name:

El problema de fons és el mateix que amb /dev/sda1 a /etc/fstab: el nom assignat pel nucli depèn de l'enumeració del bus PCI, que pot canviar en afegir o moure maquinari. La targeta que avui és enp5s0 pot ser enp6s0 demà si insereixes una altra targeta en una ranura anterior.

I hi ha un problema d'ordre encara més greu: ip link set name és una ordre que s'executa després que el sistema hagi arrencat la xarxa. Per llavors, systemd-networkd ja haurà intentat configurar enp5s0 amb la configuració d'estacions0, o a l'inrevés, i la interfície podria acabar amb la IP equivocada. Amb udev, el canvi de nom passa en el moment de la detecció, abans que res més toqui la interfície.

A Meteora això és especialment important: si estacions0 (xarxa d'estacions) i la interfície de l'API s'intercanviessin els noms després d'un reinici, l'ingestor escoltaria a la xarxa equivocada i les lectures es perdrien sense cap missatge d'error. Una fallada silenciosa i irreversible, exactament la que cal dissenyar perquè no passi.

El subsistema d'E/S existeix perquè read(fd, buf, 1024) funcioni igual sobre un teclat a 100 B/s i sobre un NVMe a 3.500 MB/s, nou ordres de magnitud de diferència. Ho aconsegueix amb una arquitectura en capes on el programari independent del dispositiu fa tot allò comú —noms, permisos, buffering, memòria cau, errors— i cada controlador només implementa allò veritablement específic del seu model.

La classificació en bloc, caràcter i xarxa determina la interfície: els de bloc admeten accés aleatori i es munten; els de caràcter són fluxos seqüencials; els de xarxa no tenen fitxer a /dev perquè un flux de bytes fiable no descriu bé uns paquets que es poden perdre i desordenar, i per això UNIX va crear una segona abstracció, el socket, en lloc de deformar la primera. El principi «tot és un fitxer» unifica permisos, eines i composició, i descansa en un mecanisme sorprenentment simple: els números major i menor, on el major tria el controlador i el menor la instància. udev omple /dev dinàmicament i les seves regles resolen dos problemes reals: noms estables que no depenen de l'ordre de detecció, i permisos exactes que eviten haver d'executar com a root.

Hi ha tres maneres de parlar amb un dispositiu, i triar bé és qüestió d'aritmètica: espera activa quan l'espera és més curta que una interrupció (o durant l'arrencada i el pànic), interrupcions per a dispositius lents amb poques dades, i DMA per a tot allò que mogui volum, amb una reducció del cost de CPU de més de 150 vegades. Als registres s'hi arriba per ports d'E/S o per MMIO, i MMIO ha guanyat perquè la seva protecció l'aplica la MMU amb granularitat de pàgina, encara que exigeix marcar aquestes pàgines com a no emmagatzemables a la memòria cau. Finalment, les tècniques del subsistema —buffering (amb la doble memòria intermèdia aportant un 62,5 % de millora a l'ingestor), caching (un factor de 20 en la segona lectura del fitxer diari), spooling i reserva— resolen cadascuna un desajust concret, i el tractament d'errors els resol com més avall millor, deixant a dalt només allò que requereix decisió.

Hem seguit el camí d'una lectura d'estació des de la targeta fins a la memòria intermèdia de l'ingestor i hem identificat les capes, però deliberadament hem deixat tres caixes sense obrir: què fa exactament la CPU en rebre una interrupció, com un controlador es registra davant del nucli i quin contracte compleix, i com funciona el DMA per dins. També ha quedat plantejat un problema amb números: a 500.000 lectures per segon, un nucli sencer es dedicaria només a atendre interrupcions. La solució a això, i a tot l'anterior, és a Controladors, Interrupcions i Operacions d'E/S, que tanca el mòdul.