El nucli de Linux té més de 30 milions de línies de codi. El de MINIX 3 en té unes 12.000 a la seva part privilegiada. Tots dos fan essencialment el mateix, però han pres decisions oposades sobre quin codi mereix executar-se amb tots els privilegis de la màquina. Aquesta decisió —quant ficar dins del nucli i quant deixar-ne fora— és la gran qüestió arquitectònica dels sistemes operatius, i fa quaranta anys que no s'acaba de resoldre. En aquesta lliçó veuràs les respostes que s'hi han donat, entendràs per què cadascuna encerta i falla en coses diferents, i comprovaràs a meteo-01 com Linux gestiona un compromís pragmàtic amb els mòduls carregables. Al final sabràs explicar per què una fallada en un controlador de disc pot tombar el servidor sencer en un disseny i no en un altre.

1. La pregunta de fons: què va dins del nucli
2. Sistemes monolítics
3. Disseny per capes
4. Microkernel i el pas de missatges
5. El cost de rendiment del microkernel
6. Nuclis híbrids
7. Exokernel i unikernel
8. Mòduls carregables del nucli a Linux
9. Taula comparativa
10. Exemple aplicat: un controlador defectuós a meteo-01

Recorda de la primera lliçó: el codi que s'executa en mode nucli pot fer qualsevol cosa amb la màquina —accedir a tota la memòria, programar qualsevol dispositiu, deshabilitar interrupcions. El codi en mode usuari només pot demanar favors al nucli.

D'aquí en surt la tensió central del disseny:

• Com més codi hi ha dins del nucli, més ràpid va. Dues parts del nucli es comuniquen amb una simple crida a funció: uns pocs nanosegons, sense canvi de context ni còpia de dades.
• Com més codi hi ha dins del nucli, més fràgil i insegur és el sistema. Un punter erroni en qualsevol línia d'aquests milions pot corrompre qualsevol estructura del sistema. No hi ha xarxa de seguretat: en mode nucli no existeix la protecció de memòria que sí que protegeix els processos.

Totes les arquitectures que veurem són posicions diferents en aquesta balança entre rendiment i aïllament.

En un nucli monolític, tots els serveis del sistema operatiu —planificador, gestor de memòria, sistemes de fitxers, pila de xarxa, controladors de dispositius— es compilen en un únic programa que s'executa sencer en mode nucli, en un mateix espai d'adreces.

Com es comuniquen les seves parts: mitjançant crides a funció normals. Quan el sistema de fitxers ext4 necessita llegir un bloc, crida directament la funció del controlador del disc. Cost: nanosegons.

Avantatges.

• Rendiment màxim. No hi ha fronteres per travessar dins del nucli.
• Accés directe a les estructures compartides. El planificador pot consultar directament l'estat de memòria d'un procés sense demanar-ho a ningú.
• Simplicitat conceptual per a qui hi programa a dins: tot és accessible.

Inconvenients.

• Sense aïllament intern. Una fallada en qualsevol part ho pot corrompre tot.
• Difícil de mantenir. Amb milions de línies i tot accessible des de tot, les dependències implícites proliferen.
• Una part no es pot reiniciar sense reiniciar el sistema sencer.

Exemples: Linux, els UNIX clàssics, FreeBSD, MS-DOS (monolític i, a més, sense cap protecció).

Una precisió freqüent: que Linux sigui monolític no significa que estigui mal estructurat. Té interfícies internes molt clares (el VFS per a sistemes de fitxers, el model de dispositius, l'API de mòduls). El que defineix allò monolític no és el desordre sinó que tot comparteix el mateix espai d'adreces privilegiat.

El disseny per capes organitza el nucli en nivells, on cada capa només pot fer servir serveis de la capa immediatament inferior i ofereix serveis a la superior. El sistema THE (Dijkstra, 1968) en va ser l'exemple canònic, amb sis nivells del 0 (planificació) al 5 (l'operador).

L'avantatge és la comprovabilitat: pots verificar cada capa assumint que les inferiors són correctes, cosa que redueix enormement l'esforç de raonament.

El problema és que la realitat no es deixa ordenar en capes estrictes. El gestor de memòria va per sota del sistema de fitxers? Sembla que sí, perquè el sistema de fitxers necessita memòries intermèdies a la memòria. Però el gestor de memòria necessita l'àrea d'intercanvi (swap), que és al disc, que gestiona el sistema de fitxers. Hi ha una dependència circular real, i cap ordenació de capes no la resol netament.

Per això el disseny per capes pur gairebé no es fa servir, encara que la seva influència és enorme: gairebé tots els nuclis moderns estan estructurats en capes aproximades, amb nivells que se salten quan cal.

La idea del microkernel és portar l'aïllament a l'extrem: deixar en mode nucli únicament allò que és impossible de fer d'una altra manera, i treure tota la resta a processos d'usuari ordinaris anomenats servidors.

El que queda dins del microkernel és molt poc:

• Gestió d'espais d'adreces (el mínim, perquè requereix tocar la MMU).
• Planificació bàsica de fils.
• Comunicació entre processos (IPC), que és la seva funció estrella.

A fora, com a processos normals sense privilegis: el sistema de fitxers, la pila de xarxa, els controladors de dispositius, el gestor de memòria d'alt nivell, la gestió de processos.

Com es comuniquen ara les parts: mitjançant pas de missatges. Quan una aplicació vol llegir un fitxer, envia un missatge al servidor de fitxers; aquest servidor n'envia un altre al servidor del disc; la resposta recorre el camí invers. El microkernel es limita a transportar missatges d'un procés a un altre.

El que el diagrama mostra és la diferència essencial: al monolític, la caixa de mode nucli és enorme i les seves parts es criden entre si de franc; al microkernel, la caixa privilegiada és diminuta i cada interacció entre components travessa la frontera de mode dues vegades.

Els avantatges del microkernel són reals i notables:

• Aïllament de fallades. Si el controlador de disc falla, és un procés d'usuari el que mor. El sistema ho pot detectar i reiniciar-lo sense que la màquina caigui.
• Nucli verificable. seL4, un microkernel d'unes 10.000 línies, té una demostració matemàtica formal que la seva implementació compleix la seva especificació. Això és senzillament impossible amb 30 milions de línies.
• Superfície d'atac mínima. Una fallada al servidor de fitxers no dona control de la màquina, només d'aquell servidor.
• Mantenibilitat. Els components tenen interfícies explícites i obligatòries: no hi ha dreceres possibles.

Exemples: MINIX 3 (fet servir també a l'Intel Management Engine, cosa que el converteix en un dels sistemes més desplegats del món sense que gairebé ningú ho sàpiga), QNX (molt utilitzat en automoció i sistemes crítics), L4 i seL4, GNU Hurd.

Aquí hi ha el problema històric del microkernel, i val la pena quantificar-lo perquè és la raó que no hagi guanyat.

Comparem què costa que meteo-api llegeixi un bloc del fitxer del dia:

En un monolític:

En un microkernel:

Un canvi de context costa de l'ordre d'1 a 5 µs, comptant el buidatge de memòries cau i de la TLB. Si estimem 2 µs per canvi de context, el microkernel afegeix uns 8 µs de sobrecost a una operació que en un SSD triga 50 µs: un 16 % més de latència. I per a operacions que es resolen a la memòria cau de pàgines (0,08 µs), el sobrecost seria de 100 vegades la feina útil.

Aquest és exactament l'argument de Linus Torvalds al seu cèlebre debat de 1992 amb Andrew Tanenbaum, autor de MINIX. Tanenbaum sostenia que el disseny monolític era «un salt enrere cap als anys 70»; Torvalds responia que la portabilitat i el rendiment importaven més que l'elegància. Tots dos tenien raó en el seu terreny, i la història els ha donat la raó a tots dos en àmbits diferents: Linux domina els servidors, QNX domina l'automoció crítica.

Matís important i actual: el cost del pas de missatges s'ha reduït moltíssim. Jochen Liedtke va demostrar amb L4 als anys 90 que una implementació d'IPC molt acurada podia ser 10-20 vegades més ràpida que les de Mach, fins al punt de fer viable el microkernel. Descartar el microkernel citant xifres de 1990 és un error freqüent.

Un nucli híbrid adopta l'estructura conceptual del microkernel (components amb interfícies clares, alguns serveis com a servidors) però n'executa la majoria dins de l'espai d'adreces del nucli per evitar el cost del pas de missatges.

• Windows NT i tots els seus descendents: té una capa d'abstracció de maquinari (HAL), un executiu amb subsistemes ben delimitats i un micronucli intern, però els controladors i el gestor gràfic corren en mode nucli per rendiment. La decisió de moure el subsistema gràfic al nucli a NT 4.0 va ser exactament aquest compromís: més velocitat a canvi que una fallada del driver gràfic pogués tombar el sistema.
• macOS / XNU: el nom significa X is Not Unix. Combina el microkernel Mach (que aporta IPC, gestió de memòria i fils) amb un servidor BSD monolític que aporta la interfície UNIX, sistemes de fitxers i xarxa, tot al mateix espai d'adreces. Té l'estructura d'un microkernel sense pagar el cost del pas de missatges entre les seves dues meitats.

El terme «híbrid» té detractors: Torvalds ha assenyalat que un microkernel els servidors del qual corren tots en mode nucli és, funcionalment, un monolític ben estructurat. És una crítica justa des del punt de vista de l'aïllament, que és el que de debò distingeix les arquitectures.

Dues idees més radicals que convé conèixer encara que el seu ús sigui minoritari.

Exokernel (MIT, anys 90). Parteix d'una crítica: les abstraccions del sistema operatiu, encara que còmodes, imposen decisions que de vegades perjudiquen l'aplicació. Una base de dades sap millor que el sistema operatiu com ha de desar els seus propis blocs a la memòria cau, però està obligada a passar per la memòria cau genèrica del nucli.

La proposta de l'exokernel és que el nucli només protegeixi i multiplexi el maquinari, sense abstreure'l, i que cada aplicació construeixi (amb una biblioteca) les abstraccions que li convinguin. No es va adoptar mai comercialment, però la seva crítica és viva: mecanismes actuals com O_DIRECT (saltar-se la memòria cau del nucli), io_uring o l'accés a la xarxa des de l'espai d'usuari són concessions exokernel dins de sistemes convencionals.

Unikernel. Porta la idea al seu extrem pràctic: es compila l'aplicació juntament amb les parts del sistema operatiu que necessita en una única imatge que arrenca directament sobre un hipervisor. No hi ha separació entre aplicació i nucli perquè només hi ha una aplicació.

Aplicat a Meteora: un unikernel de meteo-api seria una imatge d'uns pocs megabytes que contindria el servidor HTTP, la pila TCP/IP i un sistema de fitxers mínim de només lectura. Arrencaria en mil·lisegons i no inclouria ni bash, ni ssh, ni gestor d'usuaris, ni res que un atacant pogués aprofitar. Els seus inconvenients són igual de clars: no es pot depurar entrant per SSH, cada canvi exigeix recompilar la imatge sencera, i l'ecosistema d'eines és escàs. Exemples: MirageOS, IncludeOS, Unikraft.

Linux és monolític, però no rígid. Els mòduls carregables (Loadable Kernel Modules, LKM) permeten afegir i treure codi del nucli en calent, sense reiniciar. És la resposta pragmàtica al principal inconvenient pràctic del monolitisme: no haver de compilar un nucli diferent per a cada combinació de maquinari.

Molt important: un mòdul s'executa en mode nucli, amb tots els privilegis. No hi ha cap aïllament addicional. Els mòduls aporten flexibilitat de desplegament, no robustesa.

Columna a columna:

• Module: nom del mòdul. ext4 és el sistema de fitxers, nvme el controlador de l'SSD, e1000e el de la targeta de xarxa Intel.
• Size: bytes de codi que ocupa a la memòria del nucli. xfs n'ocupa 2,1 MB.
• Used by: quants altres components en depenen. ext4 té 1 perquè hi ha un sistema de fitxers muntat que el fa servir. xfs té 0: està carregat però no es fa servir, i es podria descarregar per estalviar memòria i reduir la superfície d'atac.

Per investigar un mòdul concret:

Què cal mirar aquí i per què:

• filename: la ruta del fitxer .ko (kernel object). És codi compilat per a aquesta versió exacta del nucli; un mòdul compilat per a una altra versió no es carregarà.
• license: GPL v2: si un mòdul no declara una llicència compatible amb la GPL, el nucli es marca com a «contaminat» (tainted) i molts desenvolupadors no acceptaran informes de fallada. És un mecanisme de pressió legal i tècnica alhora.
• depends: altres mòduls necessaris. Aquí és buit; insmod fallaria si hi manquessin dependències, mentre que modprobe les resol automàticament.
• intree: Y: el mòdul forma part de l'arbre oficial del nucli, no és de cap tercer. Els mòduls fora de l'arbre (típicament controladors propietaris de targetes gràfiques) són una font clàssica d'inestabilitat.

Gestió de mòduls:

• modprobe -r descarrega. Només funciona si el Used by és 0; si alguna cosa el fa servir, falla amb Module xfs is in use. És una protecció elemental, perquè descarregar un mòdul en ús corrompria el sistema.
• modprobe (sense -r) carrega i resol dependències, a diferència d'insmod, que carrega un fitxer .ko concret sense resoldre-les.
• /proc/sys/kernel/tainted retorna 0 si el nucli és net. Un valor diferent indica que s'ha carregat alguna cosa no oficial o que hi ha hagut un error greu previ. És el primer que convé mirar quan es diagnostica una inestabilitat inexplicable.

Una lectura útil d'aquesta taula: cada arquitectura guanya en l'àmbit on la seva prioritat és la que importa. Linux domina on mana el rendiment i la varietat de maquinari. QNX domina on una fallada costa vides i cal certificar el sistema davant d'un regulador. No hi ha cap arquitectura millor en abstracte.

Imaginem que el controlador e1000e de la targeta de xarxa té un error: en una condició rara —un paquet mal format amb una longitud declarada més gran que la real— escriu 64 bytes més enllà del final d'una memòria intermèdia.

El controlador s'executa en mode nucli, al mateix espai d'adreces que tota la resta. Aquests 64 bytes s'escriuen sobre el que hi hagués a continuació a la memòria del nucli. Dos escenaris:

• Escenari visible. La zona corrompuda conté punters d'una estructura crítica. En fer-los servir, el nucli provoca un kernel panic: s'atura del tot. meteo-01 cau sencer, amb ingestor, agregador, meteo-api i tota la resta. Es perden les dades encara no abocades al disc (els 8 MB de Dirty que vèiem a la lliçó anterior) i cal reiniciar la màquina.
• Escenari pitjor: corrupció silenciosa. La zona corrompuda conté dades de la memòria cau de pàgines, concretament part del fitxer 2026-08-31.dat. No hi ha cap fallada visible. El sistema continua funcionant. meteo-api serveix durant hores lectures amb valors erronis als clients de Meteora, i més tard el nucli aboca aquesta memòria cau corrupta al disc, fent el dany permanent. Ningú no se n'assabenta fins que un client reclama.

El segon escenari és pitjor que el primer, i és la conseqüència més greu de la manca d'aïllament: no és només que una fallada pugui tombar el sistema, és que pot no tombar-lo i corrompre dades en silenci.

Si el sistema arriba a caure, en quedaria rastre:

• dmesg -T mostra la memòria intermèdia de missatges del nucli amb marques de temps llegibles (-T).
• journalctl -k filtra només missatges del nucli; -b -1 els de l'arrencada anterior, que és on hi haurà la causa de la caiguda; -p err limita a nivell d'error.

El controlador de xarxa és un procés d'usuari amb el seu propi espai d'adreces. En escriure 64 bytes fora de la seva memòria intermèdia, passa una de dues coses:

• Si l'adreça és fora de les pàgines assignades al procés, el maquinari genera una fallada de pàgina i el sistema mata el procés del controlador. La resta del sistema queda intacta.
• Si l'adreça cau dins de la memòria del controlador mateix, li corromp les seves pròpies dades, però la corrupció està confinada: no pot arribar a la memòria cau de pàgines ni a les estructures del nucli.

A MINIX 3 hi ha a més un component anomenat servidor de reencarnació (reincarnation server) que vigila els controladors i els reinicia automàticament quan detecta que han mort. El resultat pràctic seria:

• Interrupció del servei de xarxa durant uns mil·lisegons.
• Algunes lectures d'estacions perdudes, que es tornaran a enviar.
• ingestor, agregador i meteo-api continuen vius, amb les seves connexions TCP possiblement trencades però amb l'estat intacte.
• Les dades ja rebudes no es corrompen.
• Una entrada al registre i cap trucada de matinada.

Amb aquest exemple sembla evident que el microkernel és millor, i en robustesa ho és. Però cal ser just amb el conjunt:

• Aquella fallada del controlador és molt poc freqüent. Els controladors de l'arbre oficial de Linux estan provats en milions de màquines.
• El cost de rendiment del microkernel es paga en totes i cadascuna de les operacions, no només quan hi ha fallades.
• Linux té les seves pròpies mitigacions: KASLR, memòria del nucli de només lectura, verificació de signatures de mòduls, i projectes com Rust-for-Linux, que introdueix al nucli un llenguatge que impedeix per construcció precisament aquest tipus de desbordament.

Quin triar depèn del cost de la fallada. Per a meteo-01, una caiguda significa unes hores sense dades meteorològiques: molest i car, però assumible, així que Linux és la tria correcta. Per al sistema de frenada d'un cotxe, el cost de la fallada és inacceptable, i per això allà es fa servir QNX i es paga el sobrecost sense discutir.

• Creure que monolític vol dir mal estructurat. Linux està molt ben estructurat internament. Allò monolític es refereix a l'espai d'adreces compartit, no a la qualitat del disseny.
• Pensar que els mòduls carregables converteixen Linux en un microkernel. No: un mòdul s'executa amb tots els privilegis i pot corrompre el sistema exactament igual que el codi compilat a dins. Aporten flexibilitat, no aïllament.
• Descartar el microkernel citant xifres de rendiment de 1990. El treball de Liedtke amb L4 va millorar el cost de l'IPC en un ordre de magnitud, i seL4 ha demostrat que un microkernel verificat formalment és viable en producció.
• Suposar que una fallada al nucli sempre es manifesta com una caiguda. La corrupció silenciosa és més perillosa precisament perquè no es veu. Davant de dades inexplicablement errònies, comprovar /proc/sys/kernel/tainted i el registre del nucli hauria de ser un reflex.
• Instal·lar mòduls fora de l'arbre sense pensar-hi. Els controladors de tercers són una causa estadísticament destacada d'inestabilitat, i contaminen el nucli, cosa que complica qualsevol diagnòstic posterior.
• Consell: quan avaluïs una arquitectura, no preguntis «quina és millor» sinó «quant costa una fallada aquí». Aquesta pregunta ordena la decisió immediatament.

Per a cada situació, indica quina arquitectura de nucli seria més adequada i justifica la resposta amb el criteri del cost de la fallada i dels requisits de rendiment:

1. Un sistema de control d'un quiròfan robotitzat.
2. Un servidor de bases de dades que atén 50.000 consultes per segon.
3. La centraleta d'un cotxe que gestiona frens i direcció assistida.
4. Un microservei al núvol que es desplega milers de vegades al dia i només serveix una API.

Examina l'estat dels mòduls de la teva pròpia màquina Linux (o d'una màquina virtual) i respon:

1. Quants mòduls hi ha carregats i quanta memòria del nucli ocupen en total?
2. Hi ha algun mòdul amb Used by a 0 que podries descarregar?
3. Està contaminat (tainted) el nucli? Si ho està, esbrina per què.

Escriu les comandes que faries servir i explica què busques amb cadascuna.

meteo-01 pateix reinicis inexplicables cada dos o tres dies, sempre de matinada. No hi ha cap patró clar a la càrrega. Dissenya un pla de diagnòstic d'almenys cinc passos orientat a determinar si la causa és al nucli (i en quina part), justificant quina informació busca cada pas.

Solució 1

1. Quiròfan robotitzat → microkernel (QNX, seL4 o similar). El cost de la fallada és una vida humana, així que l'aïllament i la certificabilitat dominen qualsevol altre criteri. A més, aquest tipus de sistema ha de passar certificacions (IEC 62304, IEC 61508) que exigeixen demostrar el comportament del programari; amb un nucli de 30 milions de línies això és inabordable, mentre que seL4 aporta una verificació formal completa. El rendiment requerit és modest: moure un braç robòtic no exigeix milions d'operacions per segon, sinó que cadascuna arribi a temps.

2. Servidor de bases de dades a 50.000 consultes/s → monolític (Linux). Aquí mana el rendiment. A aquest ritme, cada microsegon de sobrecost per operació es tradueix en costos reals de maquinari. El sobrecost del pas de missatges seria inacceptable. A més, el cost d'una fallada és alt però acotat: una caiguda significa indisponibilitat i recuperació des del journal, no un dany irreversible. La resposta correcta al risc aquí no és canviar d'arquitectura sinó replicar: diverses màquines amb commutació per error. Nota addicional: les bases de dades són precisament el cas d'ús que va motivar la crítica exokernel, i per això fan servir O_DIRECT per gestionar la seva pròpia memòria cau.

3. Centraleta de frens → microkernel de temps real (QNX és l'estàndard de facto en automoció). Combina les dues exigències més dures: cost de fallada inacceptable i terminis estrictes. Necessita aïllament (que una fallada al mòdul d'infoentreteniment no toqui el de frenada) i determinisme (resposta garantida en un temps acotat). És l'escenari on el sobrecost del microkernel es paga sense discussió, i on a més la separació de components permet certificar cadascun a un nivell de criticitat diferent.

4. Microservei al núvol → unikernel, o alternativament contenidor sobre Linux. L'unikernel hi encaixa bé: la imatge és mínima (megabytes), arrenca en mil·lisegons (important si s'escala sota demanda), i la seva superfície d'atac és diminuta perquè no inclou ni shell ni utilitats. Els seus inconvenients principals —dificultat de depuració i impossibilitat d'entrar a la màquina— importen poc en un desplegament immutable on la resposta davant d'un problema és reemplaçar la instància. A la pràctica, però, l'opció dominant avui és un contenidor sobre Linux, perquè l'ecosistema d'eines és incomparablement millor: és un exemple clar que la maduresa de l'ecosistema pesa tant com els mèrits tècnics.

Solució 2

1. Nombre de mòduls i memòria ocupada:

• lsmod llista els mòduls; tail -n +2 descarta la línia de capçalera per no comptar-la ni sumar-la.
• wc -l compta les línies restants, és a dir, els mòduls.
• A la segona comanda, awk acumula la segona columna (Size, en bytes) a la variable suma i al final (END) la imprimeix convertida a MB. Un sistema d'escriptori típic té entre 80 i 150 mòduls i 20-40 MB; un servidor minimalista, bastants menys.

2. Mòduls descarregables:

• $3 == 0 selecciona les línies la tercera columna de les quals (Used by) és zero, és a dir, mòduls que ningú no fa servir ara mateix.
• Advertiment important: Used by a 0 no garanteix que sigui segur descarregar-lo. Un mòdul d'un sistema de fitxers pot estar a 0 i caldre tan bon punt es munti un dispositiu d'aquell tipus; un mòdul de so a 0 deixarà de funcionar tan bon punt es reprodueixi alguna cosa. En un servidor de producció, no es descarreguen mòduls a la lleugera: el correcte és incloure'ls a la llista negra (/etc/modprobe.d/blacklist.conf) i verificar-ho després d'un reinici controlat.

3. Nucli contaminat:

• Si retorna 0, el nucli és net i no hi ha res més a investigar.
• Si retorna un altre número, és una màscara de bits on cada bit indica un motiu. Per interpretar-la:

El bucle comprova bit a bit quins estan actius mitjançant un desplaçament (1 << i) i un AND lògic. Els motius més habituals són el bit 0 (mòdul propietari carregat, típicament el controlador d'NVIDIA), el bit 12 (mòdul fora de l'arbre oficial) i el bit 7 (la màquina va patir prèviament una fallada greu de la qual es va recuperar). Aquest últim és el més rellevant per diagnosticar inestabilitat: indica que ja ha passat alguna cosa dolenta encara que el sistema continuï dret. La segona línia busca el missatge explicatiu que el nucli sol deixar en el moment de contaminar-se.

Solució 3

Pas 1: va ser una caiguda o un reinici ordenat?

last -x mostra l'historial d'arrencades i aturades. Si hi apareix shutdown, algú o alguna cosa ho va ordenar (una actualització automàtica, un temporitzador). Si només hi apareix reboot sense shutdown previ, va ser una caiguda. Aquesta distinció és la primera bifurcació del diagnòstic i estalvia investigar en la direcció equivocada.

Pas 2: buscar el rastre a l'arrencada anterior.

-b -1 accedeix a l'arrencada anterior, que és on hi haurà la causa. Si els últims missatges mostren Kernel panic, Oops, BUG: o un Call Trace, tenim la pila de crides de la fallada i podem identificar el mòdul implicat. Si el registre es talla de cop sense cap error, és molt sospitós d'un problema de maquinari o d'un tall d'alimentació, perquè una fallada de programari gairebé sempre deixa alguna cosa escrita.

Pas 3: comprovar contaminació i mòduls de tercers.

Un nucli contaminat per un mòdul fora de l'arbre és un candidat immediat. El bucle recorre els mòduls carregats i assenyala els que no formen part de l'arbre oficial.

Pas 4: correlacionar amb l'activitat de matinada.

Que els reinicis siguin sempre de matinada és la pista més forta de l'enunciat. Cal esbrinar què passa a aquella hora: l'agregador de les 02:30, una còpia de seguretat, una actualització automàtica de paquets, una anàlisi d'integritat. Si el reinici coincideix sistemàticament amb una d'aquestes tasques, aquella tasca sotmet el sistema a una càrrega concreta (E/S intensiva, pressió de memòria) que dispara la fallada latent.

Pas 5: descartar causes que no són del nucli.

Abans de culpar el nucli cal descartar tres sospitosos habituals: que l'OOM killer hagi actuat (manca de memòria, no fallada del nucli), que el disc estigui degradat (els atributs SMART de sectors reassignats o pendents el delaten) i que hi hagi errors de memòria RAM. Un mòdul de RAM defectuós produeix exactament aquest quadre: caigudes aleatòries, sense patró de programari, sovint sota càrrega. Per confirmar-ho, memtest86+ durant diverses hores és la prova definitiva.

Pas 6 (si res de l'anterior no conclou): habilitar diagnòstic persistent.

kdump reserva memòria per arrencar un nucli secundari després d'un panic i abocar la imatge de memòria del nucli caigut al disc. És l'única manera d'analitzar a posteriori un panic que no va arribar a escriure's al registre. Complementàriament, si la màquina no respon en absolut, habilitar el watchdog del nucli permet reiniciar automàticament i almenys acotar la indisponibilitat mentre s'investiga.

L'arquitectura del nucli es redueix a una decisió: quant codi executar amb tots els privilegis de la màquina. El disseny monolític ho fica tot a dins i guanya rendiment a costa de no tenir cap aïllament intern; el microkernel en deixa fora gairebé tot i guanya robustesa i verificabilitat a costa del pas de missatges; els híbrids adopten l'estructura del segon amb el rendiment del primer, sacrificant l'aïllament que li donava sentit. El disseny per capes va aportar una manera de raonar que sobreviu encara que la seva forma pura sigui impracticable, i exokernel i unikernel qüestionen des de l'altre extrem si les abstraccions del sistema han de ser obligatòries.

Linux resol el problema pràctic del monolitisme amb els mòduls carregables, que aporten flexibilitat de desplegament però, convé insistir-hi, cap aïllament addicional. I l'exemple del controlador defectuós a meteo-01 deixa la lliçó clau: la manca d'aïllament no només pot tombar el servidor, sinó una cosa pitjor: corrompre dades en silenci.

La conclusió general és que no hi ha cap arquitectura millor, sinó una pregunta que ordena la tria: quant costa una fallada. Per a meteo-01, unes hores sense dades; per a un sistema de frenada, una vida.

Tot això ha girat al voltant d'una frontera que hem fet servir constantment sense explicar-la: la que separa el mode usuari del mode nucli. A la lliçó següent, Mode Usuari, Mode Nucli i Crides al Sistema, veurem exactament com funciona aquesta frontera, com es travessa pas a pas i quant costa travessar-la.