Salutations!
Au cours des dernières années, j'ai eu l'occasion d'étudier le code source d'environ trois douzaines de systèmes d'exploitation à un degré ou à un autre. Je ne me souviendrai probablement même pas de tous. Fondamentalement, il s'agissait de petites bibliothèques pour microcontrôleurs, mais les «grands» OS devaient également être visualisés avec des degrés d'immersion variables.
Pendant tout ce temps, j'ai également vu des articles sur diverses ressources sur le "développement du système d'exploitation", qui se résumaient essentiellement à la sortie de "bonjour le monde" dans QEMU, et je me suis plaint qu'il n'était pas nécessaire de confondre le système d'exploitation et "un programme qui peut fonctionner sur du métal nu" ... OS ne consiste pas du tout à travailler sur du matériel, c'est avant tout une question de synchronisation et tout ce jazz.
On pourrait soutenir que quiconque s'intéresse au développement "académique" devrait lire des livres, pas des articles HOWTO sur Internet. D'un autre côté, des livres comme les ouvrages d'E. Tanenbaum présentent également des lacunes, qui font que le flot d'articles mentionnés ci-dessus ne se dessèche pas. Le livre de Tanenbaum (sur MINIX) est encore d'un niveau assez "élevé", et de nombreuses questions qui se posent dans la pratique n'y sont pas du tout considérées. Et il y a encore une chose. Le développement de systèmes d'exploitation à usage général et de RTOS a toujours été dans des directions opposées: dans les systèmes d'exploitation de type UNIX, les processus monothread sont apparus pour la première fois, et seulement après un certain temps, les processus sont devenus multithreads; dans le domaine de RTOS, c'était l'inverse, il y avait d'abord des systèmes multithread «à processus unique», et alors seulement il pouvait y avoir plus d'un processus. Il y a une opinion que le deuxième cas est meilleur pour étudier,parce que vous pouvez commencer par quelque chose de plus simple et compliquer les choses progressivement, et finalement arriver à la même chose. Mais je m'éloigne du sujet.
Tous ces grognements de ma part ont été accueillis par d'autres et collègues avec des phrases telles que «critiquer - suggérer», «faire mieux», «le pianiste joue comme il peut», «tout le monde peut offenser l'artiste», etc. Par conséquent, un jour, la patience a manqué et j'ai dit ok, défi accepté. Et il s'est assis pour écrire sa propre version de «la bonne voie».
En passant, pour le soutien financier et moral de tout cet événement, je tiens à remercier la société Eremex, ainsi que les collègues qui ont accompli l'exploit de travail en lisant et en éditant le projet initial.
Lorsque le volume atteint 250 pages, il est devenu clair qu'il fallait s'arrêter à temps. Ce travail, en général, est resté inachevé, mais, néanmoins, je pense que, même sous cette forme, le livre illustre bien le concept et peut être utile à ceux qui s'intéressent au sujet. Selon les critiques, il est assez difficile de le lire, donc s'il y a des suggestions sur la façon de résoudre ce problème, je leur en serais reconnaissant.
À mon avis, l'OS est la réponse à un ensemble de problèmes qui se posent lorsqu'il est nécessaire d'organiser le travail de plusieurs tâches indépendantes. Par conséquent, vous devez commencer par une description des problèmes et des approches possibles de leur solution, et pas seulement dire que cela s'est produit historiquement, discutons exactement de la façon dont cela s'est produit. Le livre n'est donc pas si opposé aux œuvres classiques, mais les complète plutôt et offre une vision légèrement différente des choses du côté des systèmes embarqués et du RTOS.
Je voudrais discuter des problèmes auxquels sont confrontés non pas le théoricien qui étudie le cours des systèmes d'exploitation à l'université, mais le programmeur. Par conséquent, des questions telles que "pourquoi le changement de contexte synchrone n'est-il pas une bonne idée en général?", "Qu'est-ce qui change qualitativement dans le noyau lorsqu'il est nécessaire de prendre en charge des processus isolés?" etc.
Il y a aussi un point de vue que les systèmes d'exploitation doivent encore subir une transformation architecturale et idéologique similaire à celle vécue par les compilateurs en raison de la division en un frontend et un backend sous la forme de LLVM. Au début, aucun effet n'a été vu de cette séparation; le programmeur a utilisé le compilateur de la même manière avant et après. Mais c'est précisément cette séparation qui a rendu possible l'émergence de Rust et d'autres langages, dont les créateurs ont pu immédiatement se concentrer sur la sémantique de leur langage, et utiliser un backend prêt à l'emploi. De même, il serait souhaitable de diviser le système d'exploitation en plusieurs parties afin que tout cela soit écrit par différentes personnes en tant que projets indépendants. FX-RTOS est
utilisé pour illustrer les principes décrits.comme l’une des approches possibles de ce problème. Bien entendu, pour pouvoir décrire certaines parties du noyau sans toucher aux autres parties, il doit être écrit de manière à le permettre. Bien qu'ici, je mette un peu la charrette en avance sur les boeufs, car au début le système d'exploitation lui-même est apparu, puis il est devenu clair que son architecture est bien adaptée pour étudier le sujet à l'aide de son exemple, car vous pouvez augmenter la fonctionnalité par très petites étapes et entrer tous les concepts progressivement.
Les sources mentionnées ci-dessus peuvent être utilisées pour illustrer des concepts jusqu'au chapitre 6 inclus, alors vous pouvez déjà passer en douceur à MINIX.
Pour que tout ne ressemble pas à un saut au départ, j'ai dû ajouter les deux premiers chapitres, qui sont consacrés aux concepts généraux et au matériel. Les programmeurs peuvent les ignorer sans affecter la compréhension du reste.
Vous pouvez télécharger le livre gratuitement sans inscription ni SMS ici .
Merci à tous pour votre attention, les critiques critiques sont les bienvenues, mais si elles comptent plus de deux phrases, il est préférable d'écrire dans des messages privés, car les commentaires ont tendance à se développer et à se transformer en un arbre de discussion de questions connexes, ce qui est difficile et peu pratique à travailler.
PS Si le sujet s'avère intéressant, j'écrirai plus tard sur FX-RTOS lui-même.