Saudações!
Nos últimos anos, tive a oportunidade de estudar o código fonte de cerca de três dúzias de sistemas operacionais em um grau ou outro. Eu provavelmente nem vou lembrar de todos eles. Basicamente, essas eram pequenas bibliotecas para microcontroladores, mas os SOs "grandes" também precisavam ser visualizados com graus variados de imersão.
Durante todo esse tempo, também observei posts sobre vários recursos sobre "desenvolvimento de SO", que basicamente se resumiam à saída de "olá mundo" no QEMU, e reclamei que não havia necessidade de confundir o SO e "um programa que pode ser executado em bare metal" ... O sistema operacional não tem nada a ver com trabalhar em hardware, mas, antes de tudo, com sincronização e todo esse jazz.
Alguém poderia argumentar que qualquer pessoa interessada em desenvolvimento "acadêmico" deve ler livros, não posts da HOWTO na Internet. Por outro lado, livros como os trabalhos de E. Tanenbaum também têm deficiências, o que leva ao fato de que o fluxo de posts mencionados acima não seca. O livro de Tanenbaum (sobre o MINIX) ainda é de um nível "alto", e muitas questões que surgem na prática não são consideradas de todo. E há mais uma coisa. O desenvolvimento do SO de uso geral e do RTOS historicamente foi em direções opostas: no SO do UNIX, os processos single-threaded apareceram pela primeira vez e somente depois de um tempo os processos se tornaram multi-threaded; no domínio do RTOS, era o contrário, primeiro havia sistemas multithread de “processo único” e somente então poderia haver mais de um processo. Há uma opinião de que o segundo caso é melhor para estudar,porque você pode começar com algo mais simples e complicar as coisas gradualmente e, eventualmente, chegar à mesma coisa. Mas eu discordo.
Todo esse meu resmungo foi recebido por outros e colegas com frases como "criticar - sugerir", "fazer melhor", "o pianista toca o quanto pode", "todos podem ofender o artista" etc. Portanto, um dia a paciência acabou e eu disse ok, desafio aceito. E ele se sentou para escrever sua própria versão do "caminho certo".
A propósito, pelo apoio financeiro e moral de todo esse evento, gostaria de agradecer à empresa Eremex, bem como aos colegas que realizaram a façanha do trabalho na forma de ler e editar o rascunho inicial.
Quando o volume chegou a 250 páginas, ficou claro que era necessário parar a tempo. Este trabalho, em geral, permaneceu inacabado, mas, no entanto, acho que, mesmo nesta forma, o livro ilustra bem o conceito e pode ser útil para os interessados no tópico. Segundo os comentários, é bastante difícil lê-lo, por isso, se houver alguma sugestão sobre como corrigir isso, ficaria grato por eles.
Na minha opinião, o sistema operacional é a resposta para um conjunto de problemas que surgem quando é necessário organizar o trabalho de várias tarefas independentes. Portanto, você precisa começar com uma descrição dos problemas e possíveis abordagens para a solução deles, e não apenas dizer que aconteceu historicamente, vamos discutir exatamente como aconteceu. Portanto, o livro não é tão contrário às obras clássicas, mas as complementa e oferece uma visão ligeiramente diferente das coisas do lado dos sistemas embarcados e do RTOS.
Eu gostaria de discutir as questões que são enfrentadas não pelo teórico que estuda o curso de sistemas operacionais na universidade, mas pelo programador. Portanto, perguntas como "por que a troca de contexto síncrona não é uma boa idéia em geral?", "O que muda qualitativamente no kernel quando é necessário dar suporte a processos isolados?" etc.
Também existe o ponto de vista de que os sistemas operacionais ainda precisam passar por uma transformação arquitetônica e ideológica semelhante à experimentada pelos compiladores devido à divisão em frontend e backend na forma de LLVM. A princípio, nenhum efeito foi visto nessa separação; o programador usou o compilador da mesma maneira antes e depois. Mas foi essa separação que possibilitou o surgimento do Rust e de outras línguas, cujos criadores foram capazes de se concentrar imediatamente na semântica de sua língua, e o back-end estava pronto para uso. Da mesma forma, seria desejável dividir o SO em várias partes, para que tudo isso seja escrito por pessoas diferentes como projetos independentes. FX-RTOS é
usado para ilustrar os princípios descritos.como uma das abordagens possíveis para esse problema também. Obviamente, para poder descrever algumas partes do kernel sem tocar em outras partes, ele deve ser escrito de forma a permitir isso. Embora aqui eu coloquei o carrinho um pouco à frente do cavalo, porque a princípio o próprio sistema operacional apareceu e ficou claro que sua arquitetura é adequada para estudar o assunto usando seu exemplo, pois você pode aumentar a funcionalidade em etapas muito pequenas e entrar todos os conceitos gradualmente.
As fontes mencionadas acima podem ser usadas para ilustrar conceitos até o capítulo 6, inclusive, e você já pode passar para o MINIX sem problemas.
Para que tudo não parecesse um salto, tive que adicionar os dois primeiros capítulos, que são dedicados a conceitos e hardware gerais. Os programadores podem ignorá-los sem afetar o entendimento do resto.
Você pode baixar o livro gratuitamente, sem registro e SMS aqui .
Obrigado a todos pela atenção, críticas são bem-vindas, mas se tiverem mais de duas frases, é melhor escrever em mensagens privadas, porque os comentários tendem a crescer e se transformar em uma árvore de discussão de assuntos relacionados, o que é difícil e inconveniente de se trabalhar.
PS Se o tópico for interessante, escreverei sobre o próprio FX-RTOS mais tarde.