- TacOS es un OS hobby tipo UNIX basado en un kernel propio escrito desde cero en C y ensamblador, y puede ejecutar DOOM y varios programas pequeños de espacio de usuario
- El kernel incluye VFS, scheduler, TempFS, dispositivos, cambio de contexto, gestión de memoria virtual, asignación de marcos de página físicos y un port de Doom
- El entorno de ejecución es compatible tanto con hardware real como con el emulador Qemu, y el hardware real fue probado en la laptop del creador
- La compilación y ejecución comienzan con
git clone seguido de make run, y requieren tener instalados Xorriso, Qemu, NASM y Clang
- TacOS no está terminado para uso real; es un toy OS de hobby con varios bugs conocidos
Resumen de TacOS
- TacOS es un OS creado desde cero en C y ensamblador, con su propio kernel
- Está compuesto como un kernel tipo UNIX y puede ejecutar DOOM y varios programas de espacio de usuario pequeños
- Sus componentes principales son los siguientes
- VFS
- scheduler
- TempFS
- dispositivos
- cambio de contexto
- gestión de memoria virtual
- asignación de marcos de página físicos
- port de Doom
Entorno de ejecución y limitaciones
- TacOS puede ejecutarse en hardware real y en el emulador Qemu
- Las pruebas en hardware real se realizaron en la laptop del creador
- El proyecto no es un OS completo listo para uso real, sino un toy OS de hobby
- Tiene varios bugs conocidos
Inicio rápido
- La compilación y ejecución pueden hacerse con el siguiente comando
git clone https://github.com/UnmappedStack/TacOS
cd TacOS && make run
make run compila TacOS y lo ejecuta automáticamente en el emulador Qemu- Las herramientas necesarias son las siguientes
Comandos de compilación
make run: compila TacOS y lo ejecuta en Qemumake qemu: ejecuta en Qemu un TacOS ya compiladomake disk: compila la imagen completa de disco como tacos.isomake kernel: compila el kernel de TacOS, que es el núcleo del sistemamake libc: compila la biblioteca estándarmake userspace: compila las aplicaciones de espacio de usuariomake initrd: crea el disco RAM inicial desde el que arranca el sistemamake lint: ejecuta las reglas del linter para el kernelmake qemu-gdb: ejecuta TacOS en Qemu con GDB conectado
Depuración
- Para adjuntar GDB mientras pruebas TacOS, ejecuta
make qemu-gdb y luego conéctate al target remoto de GDB desde otra terminal
$ gdb -q
(gdb) target remote :1234
(gdb) file kernel/bin/tacos
(gdb) continue
- Al depurar el kernel, especifica
kernel/bin/tacos
- Al depurar programas de espacio de usuario, especifica
initrd/usr/bin/<program>
Licencia y reglas de contribución
- TacOS usa la Mozilla Public License 2.0
- Las contribuciones están abiertas, pero antes de enviar un pull request debes abrir un issue y recibir la asignación del cambio
- Los pull requests que solo contengan correcciones simples de typos o gramática no se fusionarán
- Los mensajes de commit deben seguir el formato
[component] change
- Los pull requests que incluyan miles de líneas de cambios en varios componentes no relacionados dentro de un solo commit gigante no serán revisados
Comunidad
- Hay un servidor de Discord para actualizaciones relacionadas con TacOS, ayuda con proyectos OSDev y conversación
1 comentarios
Comentarios de Hacker News
¡Felicidades! Seguro te da orgullo, y también está bueno que hayas elegido DOOM como prueba de concepto.
Quizá sea un poco aguafiestas que solo haga preguntas de principiante, pero me da curiosidad saber qué pasos harían falta para ejecutarlo en una laptop.
Después de compilarlo, ¿hay un proceso parecido a configurar arranque dual en una PC con Windows? Me da un poco de risa estar preguntándole a un desconocido de internet cómo ejecutar software peligroso en mi computadora.
También me gustaría saber qué libros de texto o lecturas recomendarías si alguien quisiera probar un proyecto así. En la universidad tomé sistemas operativos y materias relacionadas, pero como estudié ingeniería eléctrica/electrónica, todo fue muy abstracto y centrado en conceptos. Me gustaría tener materiales más concretos, y no tiene que ser necesariamente x64.
Si quieres escribir un kernel, primero te recomiendo ver https://osdev.wiki, y también deberías leer especificaciones relevantes como el Intel Developer Manual y las especificaciones de los drivers que vayas a escribir tú mismo.
No sé mucho sobre desarrollo de kernels que no sean x86, pero hasta donde sé la mayoría de los conceptos son iguales y solo cambia la implementación técnica. En el README del proyecto hay un enlace al servidor de Discord, donde hay gente realmente muy inteligente que con gusto te ayudará.
Está bueno, pero ¿tu taco también puede ejecutar DOOM?
Fuera de broma, es un esfuerzo realmente digno de elogio; ¡bien hecho! Lo que me da curiosidad es si, al crear TacOS, tomaste DOOM como un objetivo estándar, o si desde el principio la meta era crear un sistema operativo dedicado solo a ejecutar DOOM.
Lo pregunto por pura curiosidad. Hace casi 30 años hice un sistema operativo extremadamente básico que apenas arrancaba, para aprender y divertirme, y si existiera un sistema operativo dedicado, portable a cualquier lado, que en la práctica solo pudiera ejecutar DOOM, el meme de “¿corre DOOM?” sería mucho más irónico y divertido.
Excelente trabajo; espero que sigas.
Hacer correr Doom en sí tomó alrededor de una semana, incluyendo agregar requisitos de libc, y hubo mucho más trabajo de base preparado antes de eso.
Usé DoomGeneric, que básicamente es un fork de Doom hecho para ser muy portable. Espero que eso responda tu pregunta; también puede ser que la haya entendido mal.
Pasar desde un kernel hecho desde cero directamente hasta DOOM es como una certificación de hacker de primer nivel. Verlo correr en hardware real debe dar mucha satisfacción, y es muy genial.
Un poco tangencial, pero me he preguntado algo parecido. Me da curiosidad si ha habido muchos intentos de crear juegos que arranquen directamente en hardware de PC moderno.
Sería una forma de entrar directamente al juego sin cargar todo un sistema operativo, parecido a las consolas de videojuegos de generaciones anteriores. Para mantenerlo simple, cosas como Wi-Fi, Bluetooth y GPU serían difíciles de aprovechar sin drivers modernos, pero el teclado y el mouse parecen bastante viables porque existe algo como acceso básico vía BIOS. Quizá estoy usando mal los términos, pero espero que se entienda la idea.
Si no quieres meterte con E/S de disco, la gran limitación es que debe ser de 512 bytes o menos. Básicamente estás ejecutando el programa como registro maestro de arranque. Si necesitas más espacio, tienes que leer algunos LBA desde el disco; hay interrupciones para eso, y en osdev también hay mejor material.
Fuera de eso, la diferencia entre un archivo .com, normalmente con la restricción de un único segmento de 64 KB, y un programa arrancable estilo MBR es bastante pequeña.
Es un trabajo realmente impresionante. Ojalá yo tuviera la habilidad para hacer algo así, pero para lograrlo seguro tuviste que leer muchas especificaciones, y esa es mi parte más débil.
Quizá sea una pregunta tonta, pero si uno quisiera usar aceleración por GPU aunque fuera en una forma muy pequeña, me pregunto qué tan difícil sería crear un driver de GPU. ¿Dirías que la documentación al respecto es buena?
La GPU emulada de Qemu tiene documentación bastante decente, así que podría ser posible, pero cosas como las GPU de Nvidia están mal documentadas y hasta hace poco la documentación era completamente privada. Linux también sufre con este problema, y he visto a algunos desarrolladores de sistemas operativos hobby terminar usando los drivers de GPU de Linux.
No hay muchas cosas que marque como casi imposibles, pero sinceramente no creo que algún día pueda escribir un driver de GPU realmente bueno para una GPU común.
Hola unmapped, en GitHub y Discord uso ThatOSDeveloper, y ese es mi nombre visible. No sabía que habías hecho correr Doom en TacOS; está bastante genial.
Tengo algunas dudas. Me pregunto si es el Doom original, si está en disco o en initramfs, y si usas Freedoom con el motor que estás usando o el WAD shareware de Doom.
Está muy bueno, pero hoy en día existen lenguajes de bajo nivel con seguridad de memoria, así que me da curiosidad por qué elegiste un lenguaje inseguro. Ya todos sabemos que la mayoría de los bugs de seguridad están relacionados con la memoria.
Entiendo que es un proyecto hobby, pero no entiendo por qué no retiramos los lenguajes inseguros cuando existen alternativas mejores.
He usado Rust en otros proyectos, pero en desarrollo de kernels siento que prefiero mucho más un lenguaje simple y fácil de leer que un lenguaje seguro.
¡Bienvenido al club! Hice casi lo mismo, y disfruté mucho la tranquilidad de construir algo que jamás iba a convertirse en un producto.
https://jakobbr.eu/2024/08/19/writing-my-own-x86_64-operatin...
¡Proyecto realmente genial! Me da curiosidad cómo maneja TacOS el aislamiento de procesos y la planificación.
Hay un planificador round-robin conectado al driver PIT, así que cada 10 ms el PIT genera una interrupción y se ejecuta el planificador. El planificador elige la siguiente tarea, guarda el estado actual de la tarea anterior, cambia al nuevo espacio de direcciones, cambia la pila, restaura los registros de la tarea y luego, con la instrucción iretq, cambia a modo usuario ring 3 y salta al puntero de instrucción.
Quiero saber más sobre TacOS. ¿Cómo gestiona ejecutar varios programas al mismo tiempo de forma segura?
También conviene leer la introducción: https://pages.cs.wisc.edu/~remzi/OSTEP/dialogue-virtualizati...
https://wiki.osdev.org/ tiene detalles de plataforma y otros recursos.