Hola Habr!
Mi nombre es Víctor, y este año soy el único estudiante del programa Google Summer of Code en el proyecto ReactOS. Hoy les contaré un poco sobre lo que hago como parte de la pasantía.
ReactOS admite un montón de todo tipo de sistemas de archivos diferentes para lectura y escritura (fat32, ext2,
ReiserFS ,
BTRFS ), sin embargo, solo puede arrancar desde una partición formateada en fat32. Esta primavera, decidí que era hora de comenzar a corregir esta situación, y solicité GSoC. Y así, unos meses más tarde escribo esta publicación :)
¿Por qué BTRFS? La respuesta es simple: el
controlador del sistema de archivos
WinBtrfs es actualmente el más estable y totalmente funcional de todos los que se incluyen en el código ReactOS. En esta etapa, queremos corregir los errores del kernel que evitan que otros FS se utilicen para cargar, por lo que los errores del controlador FS son completamente inútiles para nosotros.
Pero tuve que comenzar no desde el núcleo del sistema operativo, sino desde el instalador. Afortunadamente, casi todo estaba listo para el instalador: todo lo que se necesitaba era habilitar la descarga del controlador WinBtrfs en nuestro instalador (usetup) y agregar un par de líneas de código para admitir el formateo en el sistema de archivos necesario. Después de lo cual pude (casi) copiar fácilmente los archivos ReactOS a la partición formateada en BTRFS.
Rápidamente trataron con el instalador, pero la siguiente tarea es mucho más interesante. El cargador ReactOS: FreeLdr admite casi solo dos sistemas de archivos: fat32 e iso (hay código para ext2 y ntfs, pero nadie ha intentado ejecutarlo durante unos 5 años). Dado que FreeLdr repite el principio del gestor de arranque ntldr de MS, consta de dos partes: el sector de arranque al comienzo de la sección donde se transfiere el MBR al disco, y la parte principal, que pone el procesador en modo protegido, carga el núcleo ntoskrnl.exe en la memoria, y lo hace un montón de todo
(así es como se ve el proceso de arranque de ReactOS)Por lo tanto, para admitir el nuevo sistema de archivos, debe escribir el registro de arranque de la partición (VBR), cuya tarea es encontrar el archivo ejecutable de la parte principal del cargador de arranque (lo llamamos freeldr.sys) en el directorio raíz del disco, cargarlo en la memoria y transferir el control allí. Pero eso no es todo, freeldr.sys necesita un controlador de sistema de archivos de solo lectura casi completo para leer los archivos de configuración, el núcleo, los arbustos de registro, etc.
Primero, tenía que lidiar con el sistema de archivos BTRFS. Antes de esto, las cosas más difíciles que elegí fueron fat32 y ext2, por lo que me llevó mucho tiempo aprender la cosechadora BTRFS. La documentación en
wiki.kernel.org ayuda a resolverlo, pero para comprenderlo completamente no fue suficiente: tenía que ir a las fuentes de grub, u-boot y otros cargadores de arranque. La
utilidad python que escribí para generar las estructuras del sistema de archivos en la consola resultó ser muy útil para estudiar la estructura del sistema de archivos. Utilizándolo, escribí el primer prototipo del sector de arranque, que extrae el gestor de arranque de un archivo binario con una imagen de disco con el sistema de archivos BTRFS.
(los elementos del directorio raíz son visibles en la imagen)Ahora es el momento para el sector de arranque real. Es complicado por el hecho de que aquí estamos trabajando en un modo de procesador real con todas las consecuencias resultantes (~ 1mb de memoria, direccionamiento segmentado y trabajando con un disco a través de interrupciones del BIOS). Expansión para fanáticos de la vieja escuela como yo :)
En las estructuras BTRFS, casi todos los campos tienen un tamaño de 64 bits, que es un código muy "hinchado", ya que las instrucciones x86 de 32 bits tenían que usarse activamente. A menudo tienes que usar construcciones como:
mov si, SOME_OFFSET lea si, [esi+ecx*8] lea si, [esi+ecx*8] lea si, [esi+ecx*8] // one element is 24 bytes long
La tarea que más tiempo requirió fue escribir el procedimiento de recorrido del árbol b, tomó más tiempo depurarlo. Y después de varias noches de insomnio, aún logré obtener el codiciado mensaje de error de la segunda etapa de descarga:
freeldr.sys logró cargar con éxito en la memoria, y ni siquiera necesitó usar magia como el
modo irreal . ¡640kb es suficiente para todos!
El código del sector de arranque se puede ver en mi repositorio
github (la refactorización aún lo está esperando), y todo el trabajo en BTRFS en
este hilo.
Ahora es el turno de la segunda parte del gestor de arranque: debe enseñarle a leer el archivo de configuración del nuevo sistema de archivos. Sigue las noticias!