<html><head><meta name="color-scheme" content="light dark"></head><body><pre style="word-wrap: break-word; white-space: pre-wrap;">\section{Disco RÃ­gido}

El driver de disco rÃ­gido existente fue diseÃ±ado originalmente
de manera simple para solo soportar lectura. Si bien se hizo un intento de
soportar escritura, nunca fue terminado. El primer paso consistiÃ³ en
agregar \textbf{escritura para el hdd}.

El SO soporta el uso de device nodes (archivos que representan dispositivos en
el fs, ubicados en /dev), pero la manera en que estaba hecho era desordenada y
prensentaba problemas para habilitar el sistema booteando del hdd. El segundo
paso fue creado el mÃ³dulo \textbf{devfs}.

Se aplicÃ³ una polÃ­tica mÃ¡s eficiente para el uso del hdd (o cualquiera sea el
dispositivo base) desde el sistema de archivos. Ã‰ste tercer paso involucrÃ³
mejorar el uso de \textbf{refcounts} y agregar la idea de \textbf{dirty} al FS.

Por Ãºltimo se arreglaron varios problemas generales, bugs lÃ³gicos en el cÃ³digo y
se reestructuraron funciones importantes.

\subsection{Escritura para el HDD}

Se mantuvo la decisiÃ³n original de usar PIO para la lectura/escritura, lo que
significa que todas las transmisiones se realizaron a travÃ©s de los puertos, sin
DMA.

Para lograr la escritura se adaptÃ³ parte del cÃ³digo responsable de leer del
dispositivo. La mayor parte del cÃ³digo es simple, se ubican los valores
requeridos en los puertos especificados y se lee/escribe lo necesario.

La parte mÃ¡s tumultosa de la implementaciÃ³n tiene que ver con la espera del
dispositivo. En varias ocasiones es necesario aplicar esperas forzosas de 400ms
para que el darle tiempo al disco de procesar los comandos. Ã‰sto es
particularmente importante a la hora de escribir, y trajo muchos problemas hasta
que se descubriÃ³ que usar el comando de asm "rep" no era posible, ya que el
disco no lograba leer lo suficientemente rÃ¡pido los datos ingresados. Agregando
un pequeÃ±o delay entre cada palabra, y esperando la bajada de la bandera BUSY
luego de cada sector, se logrÃ³ soportar la escritura por puertos.

\textbf{Ver $drivers/hdd$.}

\subsection{DevFS}

Originalmente cada driver era el encargado de crear su propio device node en el
FS. Esto tenÃ­a dos problemas crÃ­ticos: creaba una dependencia innecesaria de todos
los drivers con el FS, y resultaba en problemas a la hora de querer usar algÃºn
dispositivo como base para el FS, creando una dependencia circular.

Por esta razÃ³n se creÃ³ una interfaz independiente encargada de crear device
nodes. De esta manera los drivers son inicializados, luego es el turno del
filesystem (tomando algÃºn device previo como base), y por Ãºltimo devfs se
encarga de crear los device nodes correspondientes.

Esta estrategia es la utilizada originalmente por sistemas como Linux, tomando
responsabilidad de la creaciÃ³n de estos archivos virtuales. En la actualidad se
opta por una estrategia mÃ¡s modularizada, exponiendo informaciÃ³n de dispositivos
y dejando que applicaciones de user-space manejen los device nodes (como es el
caso de udev). Actualmente esto simplemente lista los nodos a crear, se deja como
trabajo a futuro crear directorios como /sys y empujar cÃ³digo fuera del kernel
hacia aplicaciones comunes.

\textbf{Ver $kernel/devfs.c$.}

\subsection{Refcounts y Dirty en el FS}

La tÃ©cnica original del sistema de archivos para grabar en el dispositivo donde
reside era la mÃ¡s simple, hacerlo siempre. Cada estructura del FS (esto incluye
a los inodos y los bloques) lleva su correspondiente refcount o contador de
referencias, y una vez que Ã©ste llega a 0 la estructura es liberada y grabada en
el dispositivo que soporta al FS.

La primer mejora consistiÃ³ en revisar el mantenimiento de este refcount,
asegurandose de no perder referencias y dejar inodos/bloques sin liberar.

El cambio mÃ¡s importante fue el uso del flag "dirty". Siendo cuidadoso de marcar como
sucia toda estructura que reciba cambios en su ciclo de vida, es posible reducir
en un enorme grado la cantidad de escrituras al almacenamiento secundario.

Anteriormente leer un archivo en /a/b/c/hola.txt requerÃ­a en
una escritura por cada lectura de inodo/bloque, en total 10 escrituras
aleatorias a disco (1 bloque y 1 inodo por archivo/carpeta, mÃ¡s el root).
El uso de dirty eliminÃ³ todas estas ineficiencias, haciendo que esta
operaciÃ³n no escriba nunca en disco.

\textbf{Ver $fs/$ en general, en particular $inode.c$.}
</pre></body></html>