Universidade Federal de Santa Catarina
Centro Tecnológico
Curso de Ciências da Computação
Prof: Antônio Augusto Fröhlich
Uma análise do texto
The Flux OS Toolkit:
Reusable Components for OS Implementation
Autores:
Bryan Ford
Kevin Van Maren
Jay Lepreau
Stephen Clawson
Bart Robinson
Jeff Turner
A área de desenvolvimento e pesquisa em sistemas operacionais, com certeza, apresenta muitos desafios. Muitos deles inevitáveis dada a própria natureza deste ramo de pesquisa. Há que se cuidar da complexa interação entre software e os hardwares, cuja lista de diferentes tipos e modelos jamais para de crescer. Há a exigência onipresente por alto desempenho em suas funcionalidades. Há a constante necessidade de absorver novas tecnologias para dentro da capacidade destes sistemas. Há a inevitabilidade da truculenta programação em baixo nivel. A lista de exigências é extensa.
O texto que vou analisar aqui faz referência a esses problemas lembrando que a maioria deles já foi resolvido. E resolvido não apenas uma vez, mas varias, repetidas vezes por diferentes programadores. Todos aqueles envolvidos em sistemas operacionais sabem bem disso. E sabem do trabalho enorme envolvido na elaboração de um SO “from scratch” por isso já concluíram, há muito tempo, que não se deve reinventar a roda.
O texto desenvolvido pela equipe da Universidade de Utah não vê a necessidade de convencer o leitor disso. Entretanto é exatamente no como que se deve realizar este reaproveitamento de soluções em que reside a chave do produto destacado neste trabalho.
O termo usado no texto para indicar a metodologia normal com que isso tem sido feito é “canibalização”. Com essa palavra, que remete a costumes primitivos e bárbaros, os autores denominam e ao mesmo tempo desdenham a forma como programadores reaproveitam código bruto na velha mágica do “copy-paste”. De fato a “comida” desses programadores “canibais” é abundante e fácil de caçar. BSD, Mach e Linux, são alguns dos muitos SO’s livres que existem disponíveis na grande rede e cujos códigos abertos estão lá para qualquer um que tenha a coragem de ler e a capacidade de entender. Mas é exatamente aí, na leitura, que reside o problema. Tentar reaproveitar código bruto tende a se mostrar algo terrivelmente indigesto.
Não há dúvida que o processo de cópia de código economiza tempo se comparado com um programador que queira escrever um SO do zero, porém o “canibal” será obrigado a dissecar o extenso código antes que possa implementar nele suas próprias modificações, um trabalho ainda longo e tedioso.
A alternativa “civilizadora” dado pelos autores, apesar de simples e estar muito longe do status de “novidade”, permanece pouco usada na programação de sistemas operacionais.
A boa e velha modularização.
A idéia de modularização vem já de muito tempo. As primeiras definições surgiram na década de 60 e com o surgimento de novos paradigmas, novas tecnologias, o conceito ganhou corpo nas décadas seguintes. Principalmente com o advento da programação orientada a objetos.
Este paradigma de programação veio com a promessa de implementar com sucesso o reuso de código. O reuso de código que, naturalmente, acabaria com as continuas reinvenções de rodas em todas as áreas da informática.
Essa é também a idéia de se modularizar grandes softwares. Sub-divide-se um grande problema em problemas menores. Assim pode-se delegar facilmente tarefas num grupo de programadores. Pode-se conter a propagação de erros entre os módulos, mas sobretudo, pode se reaproveitar módulos antigos em sistemas novos sem que seja necessário sequer olhar sua estrutura interna.
É interessante notar que muitos sistemas operacionais se dizem “modularizados” muito embora seus módulos digam respeito às funcionalidades que o usuário queira instalar de seu SO e não precisamente de componentes. Isso vem do fato de que a própria palavra “módulo” permanece abrangente sendo usado para todo tipo de sub-fracionamento de sistemas. O módulo a que este texto faz referência é de interesse do desenvolvedor e diz respeito a um desenho genérico de componente, tanto no design quanto na forma como ele deve ser aproveitado durante o desenvolvimento. Porém talvez para evitar qualquer choque de definições formais o autor preferiu em muitos pontos chamar estes componentes de bibliotecas (libraries).
O produto descrito neste artigo, o Flux OS Toolkit, portanto, não é um SO mas um conjunto de bibliotecas a partir do qual SO’s podem ser construídos.
O texto aponta duas outras soluções semelhantes que já demonstraram sua validade mas que foram ainda pouco usadas. O Choices e o Taligent. Para demonstrar o porque desse tímido sucesso e, ao mesmo tempo, destacar por que o OS Toolkit representa uma vantagem sobre estas, é feito uma diferenciação entre duas concepções usadas neste tipo de solução. As técnicas “A coisa certa” (the right thing) e “Pior é melhor” (Worse is better).
A primeira seria caracterizada pela perfeição na interface em detrimento da complexidade de implementação e a segunda o contrário. Interfaces incompletas e “deselegantes” mas menos trabalho.
Fazer “a coisa certa” é descrito como a proposta ambiciosa. Talvez pudesse ser declarada ainda como a mais idealista e utópica já que “Pior é melhor” é apontado como a opção “pragmática”, a mais realista e a mais indicada para o problema em questão. Para os autores, que citaram fontes externas para defender esse ponto de vista, as necessidades reais exigem um certo relaxamento das regras formais para a obtenção de melhores resultados práticos. O Flux OS Toolkit pertence à concepção “pior é melhor” o que, argumentam seus autores, o torna mais fácil de usar e, portanto, o faz candidato mais forte a ter seu uso largamente disceminado futuramente.
O texto destaca o caminho tortuoso pelo qual trilharam seus desenvolvedores até que se chegasse no formato atual do OS Toolkit e a importância da experiência adquirida durante anos de pesquisa construindo sucessivos sistemas operacionais para a escolha do formato ideal para o Toolkit. Revelam nesse ponto que essa coleção de componentes foi criada inicialmente para solucionar um problema próprio de seu grupo de pesquisa. Na necessidade de constantemente experimentar idéias novas em seus kernels, os pesquisadores se viram forçados a gradativamente modularizar os códigos que eles próprios haviam “canibalizados”. Conseguiram assim reduzir drasticamente o tempo de desenvolvimento de novos kernels.
Estes componentes sozinhos não compunham nem compõem, nem se propõem a vir a compor um SO real nem muito menos pretendem substituir o programador de SO. Servem sim como um ponto de partida sobre o qual o programador pode se debruçar livrando-o de alguns dos trabalhos repetitivos desnecessários. Um ponto de partida que o texto afirma poder levar cerca de seis meses para ser atingido. Seis meses até que se tenha “algo interessante”.
O texto destaca com clareza exatamente o que estes componentes se propõem a fazer tomando como base aquilo que consideram ser a “vontade” do programador de sistemas operacionais. Numa única frase: o Toolkit deixa para o programador aquilo que lhe interessa programar e lhe substitui nas partes que este, muito contra a sua vontade, se vê normalmente obrigado a escrever.
É claro que a “vontade” do programador vai variar de acordo com o perfil do programador e os seus objetivos de desenvolvimento. A vantagem é que o uso de componentes é opcional. O desenvolvedor utilizará os componentes que não lhe interessam refazer, mas poderá, sempre que quiser, não usar qualquer um desses componentes se julgar que pode fazer algo melhor ou mais adaptado ao seu problema.
Destaca como exemplo para isso o fato de que, apesar do OS Toolkit ter sido feito para a arquitetura de PC’s x86, a maior parte de código architecture-specific está isolada em componentes separados podendo ser reescritos para outras plataformas se for do interesse do programador.
Outros exemplos são mostrados para exemplificar como o OS Toolkit pode diminuir consideravelmente o tempo de desenvolvimento de novos sistemas operacionais.
Um deles trata do problema clássico do desenvolvimento de sistemas operacionais em se programar um boot loader. Por norma este deve ser único para cada sistema operacional e diferenciado para cada diferente tipo de boot (disco rígido, via rede). Estudos indicaram que diferenças estruturais entre diferentes boots em diferentes SO’s se deviam apenas a desenvolvimentos apressados (o texto usa a expressão como quick-and-dirty) que impedem qualquer tipo de reaproveitamento entre diferentes versões do mesmo SO. O Toolkit pretende solucionar isso criando um padrão MultiBoot que serviria de interface entre o carregador de Boot e o SO. A idéia é que assim qualquer carregador de Boot compatível com o padrão poderia carregar qualquer SO também compatível.
Tendo estabelecido o padrão restou aos desenvolvedores do OS Toolkit construir os componentes do kernel compatíveis com o padrão assim como os componentes usados para criar o Boot-Loader.
Os autores afirmam com isso que criar um kernel mínimo do tipo “Oi mundo” que consiga dar boot usando o OS Toolkit é tão fácil quanto criar uma aplicação “Oi mundo” em C. É com certeza um grande progresso comparado com os “seis meses” que demorava até se ter algo “interessante” se programando do nada, como afirmara antes o texto, mas um kernel “oi mundo” ainda está longe de ser “interessante”.
O OS Toolkit oferece, atualmente, bibliotecas para uma lista ampla de funcionalidades. São elas: kernel bootstrapping de baixo nível, suporte a multiprocessamento, gerência de memória baseada em lista, gerência de endereços, biblioteca C, depuração da alocação de memória, particionamento de disco, leitura de sistema de arquivo, carregamento de programas, biblioteca de funções matemáticas, drivers para dispositivos, sistema de arquivos NetBSD, protocolos de rede FreeBSD e x-kernel.
Com estas ferramentas é possível implementar grande parte das funcionalidades necessárias a qualquer SO.
Indo adiante nas exemplificações o texto também cita o problema central da administração de memória.
Os autores deixam claro que a dor de cabeça envolvida nesse trabalho não está na questão de se bolar um gerenciador de memória que funcione, mas sim em fazer um gerenciador que funcione nos diferentes tipos de hardware que existem. As situações dadas como complicadoras dizem respeito a exigências feitas por certos tipos de arquiteturas por certos esquemas específicos que atendam seus desenhos internos. Certamente o tipo de problema que nenhum desenvolvedor terá muito tempo nem vontade de enfrentar.
O OS Toolkit resolve esse problema oferecendo bibliotecas de gerência de memória que já tenham tratado de todas essas questões.
O texto também aponta vantagens de sua biblioteca de linguagem C mas é na parte de drivers para dispositivos que uma das tarefas mais tediosas foi engenhosamente resumida.
É fato conhecido que criar drivers para os mais variados tipos de componentes de hardware é tarefa das mais ingratas. Além de ser um trabalho interminável, visto a quantidade de dispositivos que precisam ser adaptados ao SO, muitos destes hardwares são mal documentados.
Aqui o OS Toolkit aproveitou uma solução implementada no sistema operacional Mach 3.0 que permite a esse kernel usar drivers originalmente desenhados para o Linux. Para isso um código intermediário entre o SO e o driver emula para esse driver as características do kernel Linux fazendo com que esse funcione sem saber que, de fato, pode estar rodando num sistema operacional totalmente diferente para o qual foi projetado. Estas características emuladas são mantidas ocultas também do programador que está desenvolvendo o seu SO usando o Toolkit. Este visualizará apenas uma interface clara e bem definida.
O texto indica que “quase” nenhuma modificação do driver Linux é necessária. No entendimento deste calejado e sofrido programador que vos fala, este “quase” que o texto deixou escapar indica que o problema ainda não está resolvido e o desenvolvedor que for usar o OS Toolkit deve se preparar ainda para algumas dores de cabeça. Há que se ressaltar, porém, que a promessa de se construir futuramente um sistema operacional liberto da necessidade que se escreva código para seus drivers é extremamente animador. Eu diria até “bom demais pra ser verdade”.
O texto se vangloria de terem feito funcionar em seus SO’s 50 drivers Linux tendo sido necessárias a modificação de 150 linhas em 80 000. Embora isso represente uma grande economia de trabalho para quem originalmente teria que escrever estes drivers do zero, infelizmente não se poderá esperar que os futuros usuários dos sistemas operacionais desenvolvidos pelo OS Toolkit saiam baixando drivers Linux na web para usar em seus SO’s, o que seria, sem dúvida, algo fantástico.
Como análise final, creio que a promessa de a forma modularizada de montagem de sistemas operacionais é muito interessante, mas falta que sejam resolvidos muitos problemas antes que essa promessa possa ser realmente cumprida. Com certeza liberar o programador de ter que se preocupar com detalhes internos de hardware já é um grande passo, mas há complicadores. Essa possibilidade de abstração de certas peculiaridades da máquina amarra o usuário do Toolkit às arquiteturas suportadas pelo Toolkit, o que é mais grave quando verificamos que o OS Toolkit é para a plataforma x86. Essa limitação impede que este produto seja usado para o interessante mercado de SO’s de plataformas de sistemas alternativos ao tradicional PC.
A idéia toda, no entanto, é como a realização de algum tipo de sonho idealista. A promessa tantas vezes feita e tão mal cumprida de reaproveitamento de código e verdadeira modularização. Algo que se tem falado tanto e feito tão pouco. A idéia toda é tão lógica e correta que fica difícil de entender por que nunca se tornou realidade. Por que montar um sistema operacional não é algo simples como brincar de tijolinhos lego? Talvez só quem sabe o quão complexo se tornou o mundo do hardware terá clareza da resposta.