¡Saludos!
En los últimos años, tuve la oportunidad de estudiar el código fuente de aproximadamente tres docenas de sistemas operativos en un grado u otro. Probablemente ni siquiera los recordaré a todos. Básicamente, se trataba de pequeñas bibliotecas para microcontroladores, pero los sistemas operativos "grandes" también tenían que ser vistos con diferentes grados de inmersión.
Durante todo este tiempo, también observé publicaciones sobre varios recursos sobre el "desarrollo del sistema operativo", que básicamente se redujo a la salida de "hola mundo" en QEMU, y me quejé de que no había necesidad de confundir el sistema operativo y "un programa que puede ejecutarse en el metal". ... El sistema operativo no se trata en absoluto de trabajar en hardware, se trata, en primer lugar, de la sincronización y todo ese jazz.
Se podría argumentar que cualquier persona interesada en el desarrollo "académico" debería leer libros, no CÓMO publicaciones en Internet. Por otro lado, libros como las obras de E. Tanenbaum también tienen defectos, lo que lleva al hecho de que el flujo de publicaciones mencionadas anteriormente no se seca. El libro de Tanenbaum (sobre MINIX) todavía tiene un nivel bastante "alto", y muchas preguntas que surgen en la práctica no se consideran en absoluto. Y hay una cosa más. El desarrollo de sistemas operativos de propósito general y RTOS históricamente fue en direcciones opuestas: en los sistemas operativos tipo UNIX, aparecieron por primera vez los procesos de subproceso único, y solo después de un tiempo los procesos se volvieron multiproceso; en el ámbito de RTOS era al revés, primero había sistemas multiproceso de "proceso único", y solo entonces podía haber más de un proceso. Existe la opinión de que el segundo caso es mejor para estudiar,porque puedes comenzar con algo más simple y complicar las cosas gradualmente, y eventualmente llegar a lo mismo. Pero yo divago.
Otros gruñidos fueron recibidos por otros y colegas con frases como "criticar - sugerir", "hacerlo mejor", "el pianista toca lo que puede", "todos pueden ofender al artista", etc. Por lo tanto, un día se acabó la paciencia y dije ok, desafío aceptado. Y se sentó a escribir su propia versión de "la forma correcta".
Por cierto, por el apoyo financiero y moral de todo este evento, me gustaría agradecer a la empresa Eremex, así como a los colegas que realizaron la hazaña laboral en forma de lectura y edición del borrador inicial.
Cuando el volumen alcanzó las 250 páginas, quedó claro que era necesario detenerse a tiempo. Este trabajo, en general, permaneció sin terminar, pero, sin embargo, creo que, incluso en esta forma, el libro ilustra bien el concepto y puede ser útil para aquellos interesados en el tema. Según las revisiones, es bastante difícil leerlo, por lo que si hay alguna sugerencia sobre cómo solucionarlo, les agradecería.
En mi opinión, el sistema operativo es la respuesta a un conjunto de problemas que surgen cuando es necesario organizar el trabajo de varias tareas independientes. Por lo tanto, debe comenzar con una descripción de los problemas y los posibles enfoques para su solución, y no solo decir que sucedió históricamente, analicemos exactamente cómo sucedió. Por lo tanto, el libro no se opone a las obras clásicas, sino que las complementa y ofrece una visión ligeramente diferente de las cosas desde el lado de los sistemas integrados y RTOS.
Me gustaría discutir los problemas que enfrenta el teórico que estudia el curso de los sistemas operativos en la universidad, sino el programador. Por lo tanto, preguntas como "¿por qué el cambio de contexto sincrónico no es una buena idea en general?", "¿Qué cambios cualitativos en el núcleo cuando es necesario para soportar procesos aislados?" etc.
También existe el punto de vista de que los sistemas operativos aún no han sufrido una transformación arquitectónica e ideológica similar a la experimentada por los compiladores debido a la división en un front-end y un back-end en forma de LLVM. Al principio, no se observó ningún efecto de esta separación; el programador usó el compilador de la misma manera tanto antes como después. Pero fue esta separación la que hizo posible la aparición de Rust y otros idiomas, cuyos creadores pudieron centrarse inmediatamente en la semántica de su idioma, y el backend estaba listo para usarse. Del mismo modo, sería deseable dividir el sistema operativo en varias partes para que todo esto sea escrito por diferentes personas como proyectos independientes. FX-RTOS se
utiliza para ilustrar los principios descritos.como uno de los posibles enfoques para este problema también. Por supuesto, para poder describir algunas partes del núcleo sin tocar otras partes, debe estar escrito de tal manera que lo permita. Aunque aquí puse el carrito un poco por delante del caballo, porque al principio apareció el sistema operativo en sí, y luego quedó claro que su arquitectura es adecuada para estudiar el tema usando su ejemplo, ya que puede aumentar la funcionalidad en pasos muy pequeños e ingresar Todos los conceptos gradualmente.
Las fuentes mencionadas anteriormente se pueden usar para ilustrar conceptos hasta el capítulo 6 inclusive, luego ya puede pasar sin problemas a MINIX.
Para que todo no parezca un gran salto, tuve que agregar los dos primeros capítulos, que están dedicados a conceptos generales y hardware. Los programadores pueden omitirlos sin afectar la comprensión del resto.
Puede descargar el libro de forma gratuita sin registro y SMS aquí .
Gracias a todos por su atención, las revisiones críticas son bienvenidas, pero si tienen más de dos oraciones de largo, entonces es mejor escribir en mensajes privados, porque los comentarios tienden a crecer y convertirse en un árbol de discusión de temas relacionados, lo cual es difícil e inconveniente para trabajar.
PD: Si el tema resulta interesante, escribiré sobre FX-RTOS más tarde.