El propósito de esta "wiki", documentación web, guía, como le digas, es usarla como ayuda-memoria
personal
para el desarrollo del kernel.
No tiene que ser una página ultra estética, pero me estoy esforzando para que no se note que la hice
con html, css y js vanilla como la de algún proyecto aficionado
que anda por ahí.
Un kernel de sistema operativo mínimamente funcional (todo el Kernel Space más un user space mínimo)
puede andar fácilmente en las 15.000 líneas de código por lo que, como verás;
es humanamente imposible memorizar y comprender todo el flujo del kernel por mí mismo. Además son
muchos subsistemas complejos trabajando a bajo nivel juntos para intermediar entre hardware y
software.
IR0 es un kernel de sistema operativo multipropósito desarrollado
desde cero para arquitectura
x86-64 escrito principalmente en C y ASM (Aunque
no tengo ningún problema en incluir código de otros lenguajes especializados en performance como
Cpp o Rust).
Lo estoy creando para aprender más sobre sistemas operativos y poder usarlo como materia
prima para otro proyecto que replica a WSL2 pero con mi propio kernel.
No descarto escalarlo lo suficiente como para hacerlo usable en servidores mínimos o incluso IoT,
pero entiendo que eso es al largo (larguísimo) plazo.
Repo
de GtiHub
Discord
community
Versión: v0.0.1 pre-release candidate 1
Arquitectura: x86-64 (primaria), x86-32 (experimental), ARM (en desarrollo)
Bootloader: GRUB
Licencia: GNU GPL v3.0
Tipo: Kernel Monolítico Modular
Sintaxis ASM: Intel (NASM)
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.
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.
Para que IR0 funcione como soporte para servidores básicos y aplicaciones IoT, necesito
soporte de red fundamental pero sin la complejidad masiva del stack completo de
Linux.
En el Kernel Linux son mas o menos 1.500.000 de líneas de código SÓLO LA PILA DE RED
COMPLETA. En lugar de intentar portar todo eso, he decidido usar un enfoque más
pragmático:
Implementación básica con librería IoT:
Cómo la estructura de archivos puede cambiar constantemente, prefiero que la consultes en el Repositorio de GitHub.
- Rama principal con código estable y testeado.
- Rama de desarrollo activo donde se implementan y testean nuevas features.
- La agrego porque es la rama donde se crean feats que despues pasan al upstream mergeando a dev . Es la más inestable de todas porque es donde se integra código nuevo que también debe ser testeado y revisado antes de llegar a merge.
- En esta rama, se integran features lo suficientemente inestables como para terminar en mainline pero que pueden tener potencial a futuro.
Versión: v0.0.01 pre-release candidate 1
Arquitectura: x86-64 (primaria), x86-32 (experimental), ARM (en desarrollo)
Licencia: GNU GPL v3.0
Tipo: Kernel Monolítico Modular
SYS_EXIT(0) - Terminación de proceso SYS_WRITE(1) - Escribir a descriptor de archivo SYS_READ(2) - Leer de descriptor de archivo SYS_GETPID(3) - Obtener ID de proceso SYS_GETPPID(4) - Obtener ID de proceso padre SYS_LS(5) - Listar contenidos de directorio SYS_MKDIR(6) - Crear directorio SYS_PS(7) - Mostrar lista de procesos SYS_WRITE_FILE(8) - Escribir archivo al filesystem SYS_CAT(9) - Mostrar contenidos de archivo SYS_TOUCH(10) - Crear archivo vacío SYS_RM(11) - Eliminar archivo SYS_FORK(12) - Crear proceso hijo SYS_WAITPID(13) - Esperar proceso hijo SYS_RMDIR(40) - Eliminar directorio SYS_MALLOC_TEST(50) - Test de asignación de memoria SYS_BRK(51) - Cambiar break del heap SYS_SBRK(52) - Incrementar break del heap SYS_MMAP(53) - Mapeo de memoria SYS_MUNMAP(54) - Desmapear memoria SYS_MPROTECT(55) - Cambiar protección de memoria SYS_EXEC(56) - Ejecutar programa
Nota: Se optó por una implementación básica con librería IoT en lugar de portar el stack completo de Linux (1.5M líneas) para mantener el kernel ligero y manejable.
Espacio Kernel: 0x100000 - 0x800000 (1MB-8MB) Espacio Heap: 0x800000 - 0x2000000 (8MB-32MB, 24MB total) Espacio Usuario: 0x40000000+ (1GB+)
print(), write()
, etc. por que no hay sistema operativo que
responda a esas funciones . Vos sos el
sistema operativo. por eso, en el repo tengo la carpeta de dependencias "includes".
snake_case()
UPPER_CASE
struct_name_t
g_variable_name
CONSTANT_NAME
#INCLUDE -ir0/Lib.h -
(se estan migrando a ese formato)
- En esta sección se detallan los principales subsistemas que componen el kernel
IR0,
su estado actual de desarrollo y las características técnicas de cada uno.
La mejor forma de entender el funcionamiento interno es revisando el código fuente en el
Repositorio de GitHub.
El scheduler es el corazón del sistema de multiprocesamiento. Actualmente implementa un algoritmo Round-Robin simple como fallback, pero el objetivo es migrar a un scheduler preemptivo con esquema de prioridades similar al CFS (Completely Fair Scheduler) de Linux.
Archivos: scheduler/scheduler.c, scheduler/task.h, scheduler/switch/switch.asm
Sistema de archivos propio basado en EXT2 pero con innovaciones modernas. La característica distintiva es la integración de una base de datos vectorial para optimizar las operaciones de búsqueda y indexación de archivos.
Estado: En desarrollo activo
Archivos: fs/ext2.c, fs/victor_index.c, fs/journal.c
Sistema robusto de manejo de interrupciones y excepciones que garantiza la estabilidad del kernel y proporciona una interfaz limpia para el manejo de eventos de hardware y software.
Archivos: interrupt/idt.c, interrupt/interrupt.asm, interrupt/isr_handlers.c, interrupt/irq.c
Sistema de inicialización que prepara el entorno para la ejecución del kernel, manejando la transición desde el bootloader hasta el espacio de usuario.
Archivos: boot/boot.asm, boot/kmain.c, boot/arch.c, boot/kernel_start.c
Sistema avanzado de gestión de memoria que proporciona aislamiento entre procesos, optimización de rendimiento y protección contra accesos no autorizados.
Archivos: mm/page_alloc.c, mm/slab.c, mm/vmalloc.c, mm/protection.c
Pila de red completa basada en Linux pero optimizada para el kernel IR0, proporcionando soporte para protocolos modernos y optimizaciones específicas.
Estado: Integración con Linux networking stack
Archivos: net/tcp.c, net/udp.c, net/socket.c, net/protocols/
Framework modular para el desarrollo y gestión de drivers de hardware, con soporte para hot-plugging y gestión automática de dispositivos.
Archivos: drivers/core.c, drivers/block/, drivers/char/, drivers/net/
Framework integral de seguridad que protege el kernel y los procesos de usuarios, implementando múltiples capas de protección y auditoría de seguridad.
Archivos: security/capability.c, security/seccomp.c, security/lsm/, security/audit.c
Sistema avanzado de gestión de energía que optimiza el consumo de batería en dispositivos móviles y reduce el consumo energético en servidores, manteniendo el rendimiento.
Archivos: power/suspend.c, power/cpuidle.c, power/thermal.c, power/battery.c
Subsistema de virtualización que permite ejecutar múltiples sistemas operativos simultáneamente, con soporte para contenedores y máquinas virtuales completas.
Archivos: virt/kvm/, virt/xen/, kernel/nsproxy.c, kernel/cgroup.c
Sistema completo de monitoreo y debugging que proporciona visibilidad profunda del funcionamiento del kernel y permite el diagnóstico de problemas en tiempo real.
Archivos: kernel/trace/, kernel/debug/, kernel/profiling/, kernel/bpf/
Sistema de descripción de hardware que permite al kernel descubrir y configurar automáticamente dispositivos de hardware sin necesidad de drivers específicos hardcodeados.
Archivos: drivers/of/, drivers/acpi/, drivers/firmware/
Subsistema gráfico que proporciona aceleración por hardware, soporte para múltiples monitores y capacidades multimedia avanzadas.
Archivos: drivers/gpu/drm/, drivers/media/, drivers/video/
Sistema de audio avanzado que proporciona soporte para múltiples formatos, procesamiento de audio en tiempo real y gestión de dispositivos de audio complejos.
Archivos: sound/core/, sound/soc/, sound/pci/, sound/usb/
Sistema unificado de entrada y salida que maneja todos los dispositivos de interfaz de usuario, desde teclados y ratones hasta pantallas táctiles y sensores.
Archivos: drivers/input/, drivers/hid/, drivers/iio/