Arquitectura y "Filosofía" del proyecto

A diferencia de kernels como kernel NT (Híbrido) de Microsoft, Redox-OS (Microkernel), o el mismo MINIX kernel (microkernel), IR0 se basa en una arquitectura más similar a la que tiene Linux, que es monolítico.
Sin embargo, mi argumento principal es el del rendimiento. Entiendo que alguien podría venir y señalar que, como todo monolito, si un subcomponente se rompe, se cae todo el sistema (y tendría razón) pero lo que respondo a eso es que "¿De qué me sirve a mí que el kernel soporte seguir sin filesystem si no puedo hacer nada práctico sin él?", es decir, no tiene sentido que el kernel continúe funcionando sin uno de sus componentes clave corriendo.

Por eso no veo mejor alternativa (por ahora) que el patrón monolítico. Y además me ahorra el tener que interconectar subsistemas clave entre sí con IPC, lo que impacta de una en el rendimiento del Sistema Operativo. No es perfecto, pero es estable. No es del todo trazable y requiere escalar de a poco, pero si escala bien rinde mucho.

Sin embargo yo también tengo desacuerdos con la filosofía UNIX. Ellos (entre otras cosas y de forma resumidísima) consideran que si algo falla, que falle bien. Lo que en términos kernelísticos sería: Si se rompe el scheduler, Panic() directo. Si tenés corrupción en memoria (en espacio de kernel), Panic.
Y no es que lo cuestiono por que sí, simplemente pregunto (aunque sin soluciones todavía) "¿Por qué no rescatar el sistema en tiempo de Panic()?, o por lo menos hacer el intento".
Mas allá del punto filosófico y para resumir, el kernel es monolítico porque es más performante y siento que las piezas clave del núcleo deben trabajar sin overhead.
Sin embargo, si en el futuro necesitara integrar algún subsistema específico de forma híbrida, seguramente sería pragmático.

El Kernel Space es sagrado

Yo sé que hablo como si IR0 fuera usado por miles de personas y toda la historia, pero me voy a dar el lujo de opinar al respecto.
Entonces, el punto es que el kernel space tiene que ser sólo habitable por subsistemas que trabajen en ese Entorno, nada mas.
Entiendo que hayan ciertos fabricantes preocupados por la seguridad de sus clientes que, casualmente, tienen acceso a toda interrupción que el usuario haga (saben qué teclas presionás, el tiempo de tu sesión cada vez que prendés la compu, etc.) Y todo eso porque tienen software funcionando en el kernel space con todos los privilegios que eso implica.
RING 0 es únicamente para el kernel. Todo lo que venga del RING 3 se comunica con syscalls(), fin del comunicado.

Qué le pido prestado a Linux?

Si pretendo hacer que IR0 funcione como soporte para servidores (backends, juegos, etc), que pueda correr docker y kubernetes (al menos) y que, en algún momento, pueda funcionar como base para IoT, necesito tener en primer lugar soporte de red, con sus drivers, soporte de protocolos de red modernos mas todos los algoritmos que implementan internamente.

En el Kernel Linux son mas o menos 1.500.000 de líneas de código SÓLO LA PILA DE RED COMPLETA.
Literal, si quisiera levantarla de cero, a lo mejor pasaría una década y no estaría lista. No me siento tan zarpado la verdad.

Te muestro como sería lo que necesito de la pila de red:


Entiédase hardware como los componentes de tu MOBO que hablan con el kernel. Aparte, acá se ve clarito como el kernel intermedia entre el hard y el soft.

El mismo asunto tenemos con el soporte para contenedores. Acá el tema es un toque más tranqui porque son un par menos de líneas de código en total: unas 300.000 líneas pero igual, como pasa con la pila de red, son dos proyectos totalmente aparte.

Mas o menos esto es lo que requiere docker para andar, desde la app con su runtime, hasta sus accesos en el kernel.


Fijate que docker necesita levantar literalmente un file system virtual, además de limitar la cpu, acceder a RAM, tener una interfaz de red privada, usa los namespaces para aislar del entorno su contenido, etc.

Cómo lo voy a resolver?

Bueno, si escribir la pila red y el soporte de contenedores no es trivial, integrarlos fuera de su entorno tampoco lo es, pero es mas humano que diagramar, implementar y testear.

Muy seguramente me toque mapear las syscalls que espera esa parte de Linux al estilo Wine/Proton, o copiarles algunas de las que usan nativamente si me sirven después.

Estructura de Directorios

Cómo la estructura de archivos puede cambiar constantemente, prefiero que la consultes en el Repositorio de GitHub.

Flujo de Trabajo con Git

Cómo es el merging desde feature hasta mainline?

Básicamente, vos creás tu mejora/optmización desde un fork del repo con una rama nueva que va a ser algo como "feature/fix-scheduler" por ejemplo.
Después, hacés PR a la rama dev del upstream (no al mainline) y se hace la revisión y el merge en dado caso.
El merge a mainline depende de cuán alineado con el proyecto considere que es la feature.
Ni siquiera algunas de mis propias implementaciones las mergearía directo al mainline por esta misma razón.

¿Qué hay que saber para contribuir?

Más que nada lo siguiente:

Saber programación estructurada/funcional/orientada a objetos según sea necesario por el lenguaje.

Conocer C o C++ o Rust.

Assembly si contribuís en subsistemas muy pegados al hard, pero recomiendo conocer los básicos para saber cómo funcionan panic(), boot.asm, etc.

Conocer cómo funciona un makefile, como compilar los subsistemas por partes, por qué hay que compilar los subsistemas por separado con su propio makefile

Herramientas de desarrollo general: GIT/GitHub, como crear, cambiar, pullear y lanzar PR's entre ramas

QEMU básico. Cómo funciona la VM, como se le carga la imagen generada al compilar el kernel.

Conocer Bash es un plus para los testeos rápidos, ya que podés iniciar QEMU con un script sin repetir el comando completo.

Comunicación. Argumentar decisiones sobre las PR's, debatir sanamente al respecto.

Saber utilizar IA's en general para optimizar el debug y adaptarlo a las convenciones de código.

Saber que, al contribuir, podés ser manteiner del subsistema al que aportaste. Y si no podés dar mantenimiento recurrente al subsistema, dejarlo bien documentado.

De igual forma, no hay que ser un experto para contribuir al kernel. Simplemente con tener ganas de aprender/estudiar sobre lo que vayas a contribuir es más que suficiente.

Configuración del Entorno

Dependencias Requeridas:

Básicamente tener instalado: el compilador de C/Cpp (gcc/g++), el compilador de asm (nasm), make para la compilación y QEMU como vm de prueba.

Te daría los comandos o las webs para instalar, pero chatgpt te lo puede resolver mejor.

Cómo escribo código?

Convenciones de Nombres:

• Funciones: snake_case()
• Macros: UPPER_CASE
• Structs: struct_name_t
• Variables globales: g_variable_name
• Constantes: CONSTANT_NAME
• includes: #INCLUDE -ir0/Lib.h - (se estan migrando a ese formato)

Comentarios:

• archivos de encabezado .h de funciones documentadas
• Archivos de código fuente con comentarios en algunas funciones, pero mas acotados
• Explicación de algoritmos complejos
• TO DO's claramente marcados
• Referencias a documentación técnica

Esto es aproximado. Por lo general trato de respetar esas convenciones lo máximo que puedo.

Algo así sería en este ejemplo una archivo promedio de código fuente:

Fijate en cómo uso las llaves por debajo del nombre de la funcion y los mismo en condicionales, bucles, etc. También como directamente no las uso cuando el condicional tiene una sola línea o hay cierto nesting.

Así manejo los encabezados (o la mayoría):

Los comentarios grandes van por lo general en éstos .h y en los fuente hacemos acotaciones.

Cómo compilar (por ahora)

Scheduler

Por ahora es un Round-Robin simple. La idea es usarlo como fallback ya que el sched principal debería ser preemptivo y usa un esquema de prioridad simple (CFS o algo así).

Archivos: scheduler/scheduler.c, scheduler/task.h, scheduler/switch/switch.asm.

Filesystem

Basado en EXT2 y hecho desde cero. La única innovación sería incluir optimizacion en funciones de búsqueda con una lib de bbdd vectorial en la que contribuí.

Archivos: A implementar.

Sistema de Interrupciones

IDT de 256 entradas, manejo de page faults, handlers y wrapper en ensamblador.

Archivos: interrupt/idt.c, interrupt/interrupt.asm, interrupt/isr_handlers.c con sus encabezados.

Subsistema de arranque

Arranque dependiendo de la arquitectura (X86_64) con punto de entrada en ASM.

Archivos: boot.asm, kmain.c arch.c, kernel_start.c.

La descarga del binario del kernel se expondrá en esta sección cuando salga la primer versión estable de la rama mainline.