Hem parlat a les cinc lliçons anteriors d'una frontera invisible: la que separa el codi de les teves aplicacions del codi privilegiat del sistema. Ha aparegut en parlar de què és el nucli, en classificar arquitectures i en seguir una petició HTTP. Ha arribat el moment de mirar-la de prop. En aquesta lliçó entendràs com el maquinari fa possible que el sistema operatiu es defensi dels programes que executa, què passa exactament —instrucció a instrucció— quan ingestor desa una lectura al disc, i per què una operació aparentment trivial com write() costa centenars de vegades més que una crida a funció normal. Quan acabis sabràs llegir la sortida de strace, que és probablement l'eina de diagnòstic més reveladora que hi ha a Linux, i entendràs per què el buffering no és un detall d'implementació sinó una decisió de rendiment de primer ordre.

1. Per què un programa no pot tocar el maquinari
2. El mode dual: bit de mode i instruccions privilegiades
3. Anells de privilegi
4. Què és una crida al sistema
5. El recorregut pas a pas, d'usuari a nucli i tornada
6. API, biblioteca C i crida al sistema: tres coses diferents
7. Categories de crides al sistema
8. Exemple en C: write() davant de fprintf()
9. Observació real amb strace
10. El cost d'una crida al sistema i per què convé minimitzar-les

Comencem pel problema. Suposa que meteo-api, un programa ordinari, pogués executar qualsevol instrucció de la CPU i accedir a qualsevol adreça de memòria. N'hi hauria prou amb una fallada, o amb un atacant que hagués compromès el procés, perquè:

• Llegís la memòria d'ingestor i obtingués dades d'altres clients.
• Escrivís directament al disc, saltant-se el sistema de fitxers i els permisos, i modifiqués /etc/shadow.
• Deshabilités les interrupcions i monopolitzés la CPU per sempre: ni tan sols el temporitzador la podria recuperar.
• Reprogramés la taula de pàgines per accedir a tota la RAM física.

Fixa't en un matís decisiu: no n'hi ha prou que el sistema operatiu «no el deixi». Si el programa pot executar la instrucció que reprograma la MMU, l'executarà i el sistema no tindrà manera d'impedir-ho, perquè per aleshores ja s'ha executat. L'única solució possible és que el maquinari s'hi negui.

I aquí hi ha la idea central de tota la protecció en informàtica: la seguretat d'un sistema operatiu no descansa en el seu codi, sinó en un mecanisme del processador que el programari no pot eludir.

La CPU té un bit de mode al seu registre d'estat que indica en quin mode s'està executant:

Certes instruccions són privilegiades: si s'intenten executar en mode usuari, la CPU no les executa i genera una excepció. En x86-64, alguns exemples:

Pots comprovar a la pràctica que la protecció funciona:

Què ha passat, línia a línia:

• __asm__ volatile ("cli") insereix directament la instrucció màquina cli al programa. volatile impedeix que el compilador la reordeni o l'elimini per considerar-la inútil.
• La CPU, en trobar-se cli amb el bit de mode a «usuari», no l'executa. Genera una excepció de protecció general.
• El nucli atén aquesta excepció, comprova de quin procés ve i li envia el senyal SIGSEGV, que per defecte acaba el procés.
• El segon printf no s'executa mai.

Això és exactament el que volíem demostrar: la negativa no ve del sistema operatiu, ve del silici. El sistema operatiu només decideix què fer després.

Aquí hi ha la part elegant del disseny. Si un programa pogués posar el bit de mode a «nucli», tota la protecció seria inútil. Per això el bit no es pot modificar directament. Només canvia a mode nucli en tres circumstàncies, i en totes tres el control salta simultàniament a una adreça que el nucli va fixar per endavant:

1. Una interrupció de maquinari (el disc ha acabat, ha arribat un paquet de xarxa). És asíncrona, no la provoca el programa.
2. Una excepció (divisió per zero, fallada de pàgina, instrucció privilegiada). És síncrona però involuntària.
3. Una crida al sistema, és a dir, una petició voluntària del programa.

En els tres casos, el canvi de mode i el salt són una sola operació atòmica del maquinari. No hi ha cap instant en què s'estigui en mode nucli executant codi triat pel programa. Aquesta atomicitat és el que fa que el sistema sigui segur.

L'arquitectura x86 generalitza el mode dual a quatre nivells o anells, numerats del 0 (privilegi màxim) al 3 (mínim). La idea, heretada de Multics, era permetre nivells intermedis: per exemple, controladors a l'anell 1, amb menys privilegis que el nucli però més que les aplicacions.

A la pràctica, gairebé tots els sistemes fan servir només el 0 i el 3, per dues raons: perquè altres arquitectures (ARM, RISC-V, MIPS) només ofereixen dos nivells i fer-ne servir quatre trencaria la portabilitat, i perquè els nivells intermedis compliquen molt el disseny per a un benefici discutible. Una dada curiosa: els anells 1 i 2 sí que es van arribar a fer servir en algunes tècniques de virtualització abans que existís el suport de maquinari.

La virtualització moderna sí que va afegir un nivell: l'anomenat anell -1 o mode arrel VMX, on s'executa l'hipervisor, per sota de l'anell 0 dels sistemes convidats. Ho veuràs a Virtualització: Hipervisors i Màquines Virtuals.

Una crida al sistema (system call o syscall) és l'única porta legítima perquè un programa en mode usuari demani alguna cosa al nucli. És una petició voluntària i controlada de travessar la frontera.

Tres característiques la defineixen:

• El punt d'entrada el tria el nucli, no el programa. El programa no pot saltar a una adreça arbitrària del nucli. Només pot dir «vull la crida número 1» i el nucli decideix quin codi executa.
• Els arguments es validen. El nucli comprova que els punters que li passes apunten a memòria que realment és teva, que el descriptor de fitxer existeix, que la mida és raonable. Cap comprovació no és opcional: cadascuna tapa un forat de seguretat.
• El retorn torna al mode usuari. Quan la crida acaba, el bit de mode torna a «usuari» i l'execució continua just després de la instrucció que va provocar l'entrada.

Linux té unes 350 crides al sistema en x86-64. En pots veure la llista completa:

Aquell número de l'esquerra és el número de crida al sistema, i és el que el programa posa en un registre per indicar què vol. Els números són estables per sempre dins d'una arquitectura: si canviessin, tots els binaris existents deixarien de funcionar. Per això read és el 0 i write l'1 des de fa dècades.

Seguim el que passa quan ingestor executa write(fd, &lectura, 24).

Detallem les fases:

1. Preparació dels arguments (mode usuari). La convenció de crida de Linux en x86-64 fixa quin registre porta cada cosa:

Observa que es fa servir r10 i no rcx per al quart argument, a diferència de les crides a funció normals. La raó és purament mecànica: la instrucció syscall destrueix rcx en desar-hi l'adreça de retorn.

2. La instrucció syscall. Una única instrucció màquina que, atòmicament:

• Desa el comptador de programa (rip) a rcx i els flags (rflags) a r11.
• Carrega a rip l'adreça que el nucli va escriure en arrencar al registre especial MSR_LSTAR.
• Canvia el bit de mode a nucli.

Res d'això no ho controla el programa: l'adreça de destinació la va fixar el nucli molt abans.

3. Canvi de pila. El nucli no pot fer servir la pila del procés d'usuari, perquè el seu contingut podria estar manipulat o apuntar a memòria no vàlida. Cada procés té una pila de nucli separada (16 KB a Linux x86-64) i el nucli hi canvia immediatament. Aquest és un dels detalls que més es passen per alt i és essencial per a la seguretat.

4. Despatx i validació. El nucli comprova que rax sigui dins del rang de crides vàlides i consulta la taula de crides al sistema per saltar a la funció corresponent (sys_write). Després valida cada argument. Per exemple, per al punter fa servir copy_from_user() en comptes de llegir directament: aquesta funció comprova que l'adreça pertany a l'espai del procés. Un nucli que desreferenciés directament un punter d'usuari tindria una vulnerabilitat crítica.

5. Execució de la feina real. sys_write localitza el fitxer a partir del descriptor, copia els 24 bytes a la memòria cau de pàgines i actualitza la mida del fitxer.

6. Retorn. El resultat es col·loca a rax, es restauren els registres i la instrucció sysret retorna el rip i els flags desats, i posa el bit de mode a «usuari».

7. Traducció de l'error. Aquí passa una cosa que confon molta gent. El nucli no fa servir errno: retorna l'error com un número negatiu petit a rax (per exemple, -13 per a «permís denegat»). És la biblioteca C la que, en veure un valor entre −1 i −4095, fa:

Per això errno és una variable de la biblioteca C, no del nucli, i per això s'ha de consultar immediatament després de la crida fallida: qualsevol altra funció de biblioteca la pot sobreescriure.

Aquesta distinció es confon constantment i aclarir-la estalvia molta confusió posterior.

Les relacions importants:

• Una funció de biblioteca pot no fer cap crida al sistema. strlen(), malloc() quan hi ha memòria a la seva reserva interna, o printf() quan només omple la seva memòria intermèdia.
• Una funció de biblioteca en pot fer diverses. fopen() fa open() i sovint fstat(). printf() amb la memòria intermèdia plena fa un write().
• Una crida al sistema pot tenir diversos embolcalls diferents. open(), open64(), creat() i fopen() acaben totes a la mateixa família de crides.
• Pots invocar una crida al sistema sense biblioteca, amb syscall(1, fd, buf, 24) o directament en assemblador. Gairebé mai no val la pena.

Un cas especialment interessant en el sentit contrari: algunes crides al sistema no travessen al nucli gràcies al vDSO (virtual Dynamic Shared Object), una petita biblioteca que el nucli mapa a l'espai de cada procés. gettimeofday() i clock_gettime() llegeixen l'hora d'una pàgina compartida de només lectura sense canviar de mode. La raó és pur rendiment: són crides tan freqüents que se'ls va fer una drecera especial.

Un patró que es repeteix a totes: les crides al sistema són deliberadament poques i de baix nivell. No hi ha cap crida «llegir un fitxer de configuració» ni «fer una petició HTTP». El nucli ofereix primitives mínimes i les biblioteques construeixen a sobre. Cada crida al sistema és una superfície d'atac i una promesa de compatibilitat per sempre, així que afegir-ne una de nova és una decisió que es pren amb molta cura.

Escriurem la mateixa Lectura de dues maneres i entendrem per què no són equivalents.

Anàlisi de la versió A (write):

• open(...) és una crida al sistema directa. Retorna un int, el descriptor, o -1 en cas d'error.
• La comprovació if (fd == -1) no és opcional: gairebé totes les fallades reals d'un servei en producció vénen d'errors no comprovats. strerror(errno) converteix el codi numèric en un missatge llegible.
• write(fd, l, sizeof(*l)) lliura els 24 bytes al nucli immediatament: una crida al sistema per cada lectura.
• La comprovació escrits != sizeof(*l) cobreix un cas que sorprèn molta gent: write pot escriure menys bytes dels demanats i retornar un número menor sense que sigui un error. Passa sobretot amb sòcols i canonades. Ignorar-ho produeix truncaments silenciosos.
• El resultat al disc són 24 bytes binaris illegibles amb cat, però compactes i de mida exacta.

Anàlisi de la versió B (fprintf):

• fopen(...) és una funció de biblioteca que embolcalla open() i a més reserva una memòria intermèdia (normalment 4096 bytes) i retorna un FILE *, una estructura de la biblioteca C, no del nucli.
• fprintf(...) formata les dades com a text i les copia a la memòria intermèdia en memòria d'usuari. En aquest cas concret, no fa cap crida al sistema: la línia generada ocupa uns 35 bytes i hi cap de sobres.
• fclose(f) buida la memòria intermèdia, cosa que sí que provoca un write(), i després tanca el descriptor.
• El resultat al disc és 118;1756636800;27.4;61.0;1013.2, llegible però de mida variable i més gran (35 bytes davant de 24).

La taula que resumeix la diferència:

L'última fila és la clau, i la quantifiquem tot seguit. La penúltima explica un fenomen freqüentíssim: un programa que mor de manera abrupta perd allò que tenia a la memòria intermèdia de la biblioteca C, i per això els registres es tallen just abans de l'error que busques. Per a això existeix fflush(), i per això stderr no té memòria intermèdia per defecte.

strace intercepta i mostra totes les crides al sistema que fa un procés. És l'eina que converteix tot l'anterior en una cosa que pots veure.

Comencem pels arguments de la comanda:

• -f segueix també els fils i els fills del procés. Sense això, en un programa amb diversos fils només en veuries una part.
• -T mostra entre <> el temps que va trigar cada crida. És l'opció més útil per diagnosticar.
• -p 1099 s'enganxa a un procés ja en execució, en aquest cas ingestor. Alternativament, strace ./programa el llança des del principi.
• 2>&1 redirigeix la sortida d'error (on strace escriu) a l'estàndard, per poder passar-la per head.

Ara la interpretació del cicle, que és el que és interessant:

1. recvfrom(7, ...) = 48 — llegeix 48 bytes del sòcol amb descriptor 7: el paquet d'una estació. El = 48 és el valor de retorn. Va trigar 9 microsegons.
2. clock_gettime(CLOCK_REALTIME, ...) = 0 — obté l'hora per segellar la lectura. Va trigar 1 microsegon: sospitosament poc per a una crida al sistema, i la raó és que es resol pel vDSO sense travessar al nucli.
3. write(9, ..., 24) = 24 — escriu els 24 bytes de la Lectura al descriptor 9, el fitxer del dia. Va trigar 21 µs.
4. recvfrom(...) = -1 EAGAIN — torna a intentar llegir del sòcol i no hi ha res. EAGAIN en un sòcol no bloquejant no és un error real: significa «ara mateix no hi ha dades, torna més tard».
5. epoll_wait(5, ..., 1000) = 1 — el procés es bloqueja esperant activitat, amb un temps màxim de 1000 ms. Va trigar 31.472 µs, és a dir, 31 ms. Durant aquest temps ingestor és en estat S i no consumeix gens de CPU: és el comportament correcte d'un servei que espera.

Per veure el resum agregat, que sol ser més útil que el detall:

Com es llegeix això, que és on hi ha el valor real de l'eina:

• epoll_wait s'emporta el 71 % del temps, però això és bo: és temps bloquejat esperant feina, no CPU consumida. Un servei sa passa la major part del temps aquí.
• La columna errors mostra 26.000 errors a recvfrom. Sembla alarmant, però són els EAGAIN esperats del sondeig no bloquejant. Molts errors a strace -c no signifiquen cap problema; cal mirar quins són.
• I aquí hi ha la troballa important: 52.000 crides a write per a 26.000 lectures rebudes. Són exactament dues escriptures per lectura. Investigant el codi descobriríem que ingestor escriu la lectura al fitxer de dades i a més una línia al registre, sense cap memòria intermèdia. Aquest és l'objectiu d'optimització, i ens porta directament a l'últim apartat.

Posem números al cost de travessar la frontera.

D'on surt aquest cost? De diverses fonts que se sumen:

• El canvi de mode i de pila en si.
• Desar i restaurar registres.
• La validació d'arguments.
• I sobretot, des del 2018, les mitigacions de Meltdown i Spectre. La principal, KPTI (Kernel Page Table Isolation), separa les taules de pàgines del nucli i de l'usuari, cosa que obliga a buidar part de la TLB a cada transició. Aquesta mitigació va multiplicar el cost de les crides al sistema per un factor d'entre 2 i 5, i va fer que el buffering passés de ser recomanable a ser imprescindible.

Amb 500 estacions enviant una lectura per minut:

Situació actual (dos write per lectura, sense memòria intermèdia):

Amb una memòria intermèdia de 4 KB per al fitxer de dades. Com que cada Lectura ocupa 24 bytes, en 4 KB n'hi caben 170:

Reducció: un factor de 170. De 7,2 segons a 0,04 segons de CPU diaris.

En termes absoluts 7 segons al dia no semblen res, i a meteo-01 amb 500 estacions probablement no ho són. Però el raonament canvia del tot si Meteora creix fins a 50.000 estacions: passaríem de 12 minuts de CPU diaris malgastats a 4 segons, i amb càrrega en ràfegues la diferència es nota com a latència, no com a consum mitjà.

La memòria intermèdia no és gratuïta. Canvia rendiment per durabilitat:

I hi ha un tercer nivell que convé distingir amb precisió, perquè gairebé ningú no ho té clar:

1. Memòria intermèdia de la biblioteca C (espai d'usuari). Es buida amb fflush(). Si el procés mor, es perd.
2. Memòria cau de pàgines del nucli. Les dades ja són fora del procés: si el procés mor, sobreviuen. Però si la màquina s'apaga, es perden.
3. Disc físic. Es força amb fsync(). Només aquí la dada és realment duradora.

La decisió d'enginyeria per a Meteora seria: fer servir memòria intermèdia per a les dades de lectures (perdre 170 lectures en una caiguda és assumible, sempre es poden retransmetre) però no per a les alertes crítiques ni per al registre d'auditoria, on cada entrada ha d'arribar al disc encara que costi. Aquest mateix compromís, en la seva forma més general, reapareixerà a Assignació d'Espai, Journaling i Integritat.

• Creure que errno ve del nucli. El nucli retorna un negatiu a rax; errno és una variable de la biblioteca C. Consulta-la immediatament després de la crida fallida, abans d'invocar cap altra funció.
• No comprovar el valor de retorn de write. Pot escriure menys bytes dels demanats sense que sigui un error. El patró correcte és un bucle que reintenti amb el que falta.
• Confondre funció de biblioteca amb crida al sistema. printf no és una crida al sistema; fopen no és open. strace és la manera definitiva de comprovar què travessa de debò la frontera.
• Pensar que write() significa «ja és al disc». Significa que és a la memòria cau de pàgines del nucli. Només fsync() garanteix durabilitat, i només si el maquinari no menteix sobre les seves pròpies memòries cau.
• Optimitzar sense mesurar. Abans de redissenyar res, strace -c durant un minut et diu exactament quines crides dominen. En el cas d'ingestor, les 52.000 escriptures van aparèixer soles.
• Abusar d'strace en producció. Alenteix el procés observat de manera considerable (pot multiplicar per 10 o més el cost de cada crida), perquè cadascuna provoca dues aturades del procés. Per a producció són preferibles eines de menys impacte com perf o bpftrace.
• Consell: quan un programa vagi lent i no sàpigues per què, executa strace -c -f durant trenta segons. En la majoria dels casos, la resposta salta a la vista a la primera línia de la taula.

Per a cadascuna d'aquestes funcions d'un programa en C, indica quantes crides al sistema provoca aproximadament i per què. Raona en termes de memòries intermèdies:

1. strlen("2026-08-31.dat")
2. printf("Lectura rebuda\n") amb la sortida redirigida a un fitxer.
3. printf("Lectura rebuda\n") amb la sortida en un terminal interactiu.
4. Un bucle que crida 1.000 vegades fprintf(f, "%.1f\n", temp) sobre un fitxer obert amb fopen.
5. Un bucle que crida 1.000 vegades write(fd, buf, 8).

meteo-api respon a cada petició HTTP escrivint una línia de 120 bytes a /var/log/meteora/meteo-api.log amb write() directe, sense memòria intermèdia. Amb 200 peticions per segon i un cost de 5 µs per crida al sistema:

1. Quanta CPU al dia es dedica només a aquestes crides?
2. Si s'hi afegeix una memòria intermèdia de 8 KB, quantes crides quedarien i quanta CPU?
3. Què es perd amb aquest canvi i en quin cas no s'hauria de fer?

Escriu un programa en C que rebi 1.000 estructures Lectura simulades i les escrigui en un fitxer, minimitzant el nombre de crides al sistema sense fer servir la biblioteca stdio (és a dir, amb write() directe). Explica'n el disseny i calcula quantes crides fa davant de la versió ingènua.

Solució 1

1. strlen(...) → 0 crides al sistema. Recorre memòria del procés mateix comptant bytes fins al terminador nul. No necessita res del nucli. És l'exemple canònic de funció de biblioteca que no travessa la frontera.

2. printf redirigit a un fitxer → 0 crides en aquella invocació. Quan la sortida estàndard no és un terminal, glibc la configura amb memòria intermèdia completa (4 KB). Els 15 bytes es copien a la memòria intermèdia i allà es queden. La crida a write() es produirà quan la memòria intermèdia s'ompli (després d'uns 270 missatges), quan es cridi fflush() o en acabar el programa de manera ordenada. Conseqüència pràctica important: si el programa mor de manera abrupta, el fitxer de sortida apareix truncat, i sovint hi falta just el missatge que explicava la fallada.

3. printf a un terminal → 1 crida al sistema. Quan la sortida és un terminal, glibc fa servir memòria intermèdia per línies: la buida en trobar un \n. Com que el missatge acaba amb un salt de línia, es produeix un write() immediat. Això explica un comportament que desconcerta molta gent: el mateix programa mostra els seus missatges a l'instant per pantalla però sembla que «no escrigui res» quan es redirigeix a un fitxer. No és cap fallada, és un canvi de política de buffering.

4. 1.000 fprintf d'uns 6 bytes → aproximadament 2 crides. 6.000 bytes en total, amb una memòria intermèdia de 4.096: es buida un cop en omplir-se i un altre en fer fclose. Reducció de 1.000 a 2.

5. 1.000 write de 8 bytes → exactament 1.000 crides. write() no té memòria intermèdia: cada invocació travessa a mode nucli. A 5 µs cadascuna són 5 ms de CPU per escriure 8 KB, quan amb una memòria intermèdia n'hi hauria prou amb 2 crides i 10 µs. És una diferència de 500 vegades, i és exactament l'error que hem detectat a ingestor amb strace -c.

Solució 2

1. Situació actual:

Un minut i mig de CPU diari dedicat exclusivament a travessar la frontera per escriure el registre. Expressat d'una altra manera: el 0,1 % d'un nucli de manera contínua, només per registrar.

2. Amb memòria intermèdia de 8 KB:

Reducció d'un factor de 68, exactament el nombre de línies que caben a la memòria intermèdia. De 86,4 a 1,27 segons.

3. Què es perd i quan no s'ha de fer:

Es perden dues coses:

• Durabilitat davant d'una caiguda del procés: fins a 68 línies de registre, que corresponen als últims 0,34 segons d'activitat. I aquí hi ha el problema seriós: són precisament les línies que descriuen el que va passar just abans de la fallada, és a dir, les més valuoses per diagnosticar-la.
• Immediatesa de l'observació: un administrador que executi tail -f sobre el registre veurà els missatges a salts de 68 en 68, amb retard variable. I les eines de monitoratge que llegeixen el fitxer detectaran els problemes més tard.

No s'hauria de fer en tres casos concrets:

• Registre d'auditoria o de seguretat. Si serveix com a evidència (qui va accedir a què i quan), perdre les últimes entrades és inacceptable. A més, un atacant que provoqui una caiguda esborraria amb ella el rastre més comprometedor.
• Registre d'errors. Convé aplicar-hi la mateixa política que a stderr: sense memòria intermèdia. El volum d'errors és baix per definició, així que el cost és menyspreable i el valor diagnòstic és màxim.
• Quan hi ha un requisit de traçabilitat extern (normatiu o contractual) que exigeixi constància de cada operació.

La solució d'enginyeria correcta és separar els fluxos: el registre d'accés, que és voluminós i poc crític, amb memòria intermèdia; i els registres d'error i d'auditoria, que són escassos i crítics, sense memòria intermèdia. És exactament el que fan els servidors web seriosos, i també la raó que journald distingeixi nivells de prioritat.

Solució 3

Explicació del disseny:

• CAPACITAT = 170 no és arbitrari. 170 × 24 = 4.080 bytes, just per sota dels 4.096 d'una pàgina. Alinear la memòria intermèdia amb la mida de pàgina aprofita millor la memòria cau de pàgines del nucli i evita que una escriptura travessi innecessàriament el límit de dues pàgines.
• buidar() fa servir un bucle, no un sol write. Això és el que distingeix el codi correcte del codi que funciona fins que un dia no. write() pot retornar menys bytes dels demanats, i el bucle avança el punter p i decrementa pendents fins a haver-ho escrit tot.
• El tractament d'EINTR cobreix un altre cas real: si arriba un senyal mentre el procés està bloquejat a write, la crida pot retornar amb -1 i errno == EINTR sense haver escrit res. No és cap error: cal reintentar-ho. Ometre-ho produeix pèrdues de dades esporàdiques i irreproduïbles, de les pitjors de diagnosticar.
• afegir() buida abans d'afegir, no després. Així la memòria intermèdia no desborda mai i l'ordre de les operacions és sempre correcte.
• El buidar() final és imprescindible. Sense ell es perdrien les últimes 150 lectures (1.000 − 5 × 170 = 150), perquè quedarien a la memòria intermèdia sense escriure. És l'equivalent exacte de fflush(), i oblidar-ho és l'error més freqüent quan s'implementa buffering a mà.

Comparació de crides al sistema:

Reducció d'un factor de 167. I fixa't en un detall que reforça el que hem vist a la lliçó: el nombre de crides al sistema no depèn de quantes dades escriguis, sinó de quantes vegades travessis la frontera. Escriure 4.080 bytes costa pràcticament el mateix que escriure'n 24, perquè el sobrecost dominant és el canvi de mode, no la còpia de les dades.

Afegit opcional per a robustesa: si aquestes lectures fossin crítiques, després de buidar() caldria cridar fsync(b.fd) per forçar l'abocament al disc físic. Costa de l'ordre de mil·lisegons, així que només es justifica quan la pèrdua de dades davant d'un tall de corrent és inacceptable.

La protecció d'un sistema operatiu no descansa en el seu codi sinó en el maquinari: el bit de mode de la CPU fa que les instruccions privilegiades simplement no s'executin en mode usuari, i el pas a mode nucli només pot passar per interrupció, excepció o crida al sistema, sempre saltant a una adreça que el nucli va fixar per endavant. Dels quatre anells de privilegi de x86, a la pràctica només es fan servir el 0 i el 3.

Una crida al sistema és l'única porta legítima a través d'aquesta frontera, i n'hem recorregut la mecànica completa: número de crida a rax, arguments en registres, la instrucció syscall, el canvi a la pila del nucli, la validació d'arguments, el despatx per taula, el retorn amb sysret i la traducció del valor negatiu a errno que fa la biblioteca C. També has vist per què API, biblioteca C i crida al sistema són tres coses diferents: printf no és una crida al sistema, fopen no és open, i strace és la manera de comprovar què travessa de debò.

I sobretot t'endús una idea amb conseqüències pràctiques diàries: travessar la frontera costa, entre 50 nanosegons i uns quants microsegons, i aquest cost no depèn de quantes dades moguis. D'aquí que el buffering no sigui cap adorn sinó una decisió de disseny que canvia rendiment per durabilitat, i que a ingestor reduiria les crides al sistema en un factor de 170. Saber on posar-lo —i on no posar-lo mai, com en un registre d'auditoria— és una d'aquelles decisions que separen el codi que funciona del codi que aguanta en producció.

Amb això tanques el mòdul 1. Saps què és un sistema operatiu, d'on ve, de quins tipus n'hi ha, quines funcions compleix, com s'organitza el seu nucli per dins i com es travessa la frontera que el protegeix. A partir d'aquí deixem de mirar el sistema des de fora i comencem a obrir-lo. Al Mòdul 2: Gestió de Recursos entrarem en la primera i més fonamental de les seves feines: Gestió de Processos, on veuràs què hi ha exactament dins d'aquella abstracció que hem fet servir a cada lliçó sense obrir-la mai, com neix un procés amb fork i execve, quins estats travessa i què passa en un canvi de context. Els tres processos de Meteora deixaran de ser noms en una llista de ps per convertir-se en estructures que sabràs llegir.