“Desde o início da evolução dos computadores modernos, tornou-se claro que o computador poderia ser um soberbo arquivista que forneceria acesso instantâneo a qualquer uma de suas informações – desde que os arquivos estivessem total e adequadamente organizados e que estivessem completamente programados os tipos de respostas que fossem pedidas ao computador” Marvin L.Minsky(1966).
O que pode ser observado ao longo da evolução dos sistemas operacionais em geral, e das abordagens adotadas na concepção de seus núcleos, é a constante busca no sentido de identificar a estrutura adequada a uma determinada realidade. Sendo uma camada de software interposta entre as aplicações e o hardware propriamente dito, sua estrutura tem um impacto fundamental na performance e abrangência das aplicações que são construídas sobre ele(MONTZ et al.,1995).
Segundo Seltzer,Small e Smith(1995),muitas das melhorias de performance citadas
em recentes pesquisas em sistemas operacionais, descrevem melhoramentos específicos na funcionalidade dos sistemas, os quais produzem aquele resultado em um determinado conjunto de casos. Geralmente, mudanças dessa natureza melhoram a performance de uma determinada aplicação, mas, em contrapartida, prejudicam as de outras.
Seltzer,Small e Smith(1995)sustentam que a busca incessante por minimização do
modelo de núcleo é uma indicação clara de que o modelo atual de sistemas operacionais não é apropriado. As interfaces atuais não fornecem a flexibilidade necessária para personalizar o núcleo a cada aplicação para viabilizar o espectro cada vez maior de aplicações diferentes com diferentes requisitos.
A afirmação a seguir resume apropriadamente o contexto atual:
“Nós falhamos no passado em sermos oniscientes39 sobre os requisitos futuros dos sistemas
operacionais. Não há razão para acreditarmos que teremos sucesso projetando uma nova interface fixa. Ao invés disso, a única solução genérica (general-purpose) é construir uma interface de sistema operacional que seja facilmente extensível.” Seltzer,Small e Smith(1995).
De uma forma geral, os sistemas operacionais convencionais apresentam uma interface fixa com um conjunto pré-definido de políticas que a implementam Essas políticas constituem o mínimo denominador comum dos requisitos necessários às aplicações (ENDO et al.,1994).Quando uma política em particular é inapropriada para uma
aplicação em particular, uma de duas alternativas deve ser selecionada: deixar a aplicação sofrer com a política inapropriada ou reimplementar o mecanismo do núcleo em modo usuário.
Sistemas de gerenciamento de banco de dados caracterizam um exemplo de aplicação que, por não dispor dos serviços adequados para gerenciamento de memória fornecidos pelos sistemas operacionais, implementam suas próprias políticas de gerenciamento da mesma a revelia do sistema (embora usando primitivas do sistema). Isto causa um impacto na performance da máquina uma vez que, a aplicação passa a competir com o sistema operacional na gerência de recursos.
Outro cenário confuso envolve os mecanismos de escalonamento dos sistemas operacionais. Projetados de forma simples, estão sendo cada vez mais submetidos a aplicações de tempo-real, multi-threaded e aplicações distribuídas. As soluções apresentadas pelos projetistas, como as propostas em Steere et al. (1999), Anderson et al. (1991),Alfieri (1994)e Iyer e Druschel(2001), são complexas. Note-se que elas poderiam
ser simplificadas facilmente, apenas provendo primitivas que permitissem às aplicações especificar suas próprias disciplinas de escalonamento(SELTZER,SMALL e SMITH,1995).
Segundo Seltzer,Small e Smith (1995), inúmeras soluções intermediárias, que
Seltzer qualifica como implantes no núcleo –kernel implants, têm sido apresentadas para
solução desse problema. Como, por exemplo, em Ballesteros et al. (1999),
Ballesteros,Hess,Kon e Campbell(1999),Hunt e Brubacher(1999),Satyanarayanan,Flinn e
Walker(1999), Golm et al.(2001)e Tamches e Miller(1999).O próprio modelo para testes
de robustez, apresentado anteriormente, utiliza este artifício para alterar a funcionalidade do sistema através da inserção de seqüências aleatórias de eventos.
Lowekamp et al.(1999)discutindo um aspecto específico de projeto relacionado ao
acesso das aplicações a interface de rede apresenta as seguintes considerações:
“Uma das questões mais espinhosas relacionadas à definição de uma interface entre aplicações e a rede é decidir quais aspectos da rede devem ser expostos às aplicações. Uma solução é expor o máximo de informações possível. Contudo, exportar informação de baixo nível ou específica do sistema conflita com outras metas, particularmente aquelas relacionadas com a portabilidade da API através de redes heterogêneas. Isto também apresenta a questão sobre aspectos de facilidade de uso e facilidade de expansão (scalability). Além disso, a Internet é muito grande para expor todas as informações. Uma alternativa é disponibilizar as informações em um nível de abstração muito alto com foco nas características de performance de interesse da aplicação. Um nível de abstração muito alto pode facilitar o uso e evitar sobrecarga (overload) de informações, mas pode também resultar em imprecisões e incertezas”.
As considerações de Lowekamp indicam uma questão de compromisso entre visibilidade e segurança não discutida por Seltzer, mas que é extremamente relevante no contexto da exposição das interfaces do núcleo às aplicações.
Segundo Seltzer,Small e Smith (1995), o problema fundamental, repetidamente trabalhado, é que a interface do sistema operacional não é flexível o suficiente para permitir às aplicações a funcionalidade e/ou a flexibilidade de que elas necessitam. Em cada caso descrito na literatura, as técnicas sugeridas enfocam um conjunto específico de sintomas, mas não resolvem o problema como um todo. A seguir são alguns exemplos são apresentados caracterizando esta afirmação.
Recentes avanços na tecnologia de componentes permitem a construção de sistemas complexos através de sua composição. No entanto, ainda é difícil desenvolver sistemas eficientes, confiáveis e dinamicamente configuráveis, visto que os componentes freqüentemente são desenvolvidos por equipes diferentes e que utilizam metodologias diferentes, o que naturalmente conduz a falhas inesperadas, comprometendo a confiabilidade do produto final.
O suporte a aplicações multimídia também possui requisitos não totalmente atendidos pelos sistemas atuais. Isto porque a performance de cada processador virtual40 (multiplexado por fatias de tempo), é influenciada pela carga dos demais processadores virtuais e os mecanismos para controlar esta interferência não são disponibilizados às aplicações. No entanto, aplicações multimídia necessitam cada vez mais de tais mecanismos. Uma forma de controlar esta interface tem sido viabilizada através do uso de vários processadores reais41 (através de cartões periféricos: sintetizadores de som, placas aceleradoras de vídeo, etc), os quais aliviam a carga do processador central executando tarefas especializadas.
Coady, Kiczales e Feeley(2000), afirmam que os projetos de sistemas operacionais
apresentam um problema sério de modularização. Segundo os autores, um estudo realizado no sistema OS/360, no início da década de 70, demonstrou que o número de módulos envolvidos em uma alteração “aumentou de 14,6% nos releases 2 a 6 para 31,9% nos releases 12 a 16, em função de interações não intencionais entre os componentes”. Esta situação parece não ter mudado uma vez que:
40Ver Figura 44 na página 179 no lado direito da linha tracejada. 41Ver Figura 14 na página 64.
“Modernos sistemas operacionais comerciais como Windows NT, necessitem que os projetistas de sistemas de arquivos third party42 estejam familiarizados com os padrões de interação que
necessariamente existe entre o sistema de arquivos, o gerente de cachê e o gerente de memória virtual. Pesquisas em sistemas extensíveis também têm falhado em suportar personalização (customization) incremental pela mesma razão. Isto é, não é possível garantir que uma alteração no sistema irá requerer um esforço proporcional a quantidade de código envolvida quando a questão refere-se à falta de localidade” Coady, Kiczales e Feeley (2000).
Conforme apresentado no capítulo 2(Pág.55), a tendência em projetos de sistemas operacionais, ao longo do tempo, tem sido no sentido de mover-se partes de código tradicionalmente encontrado no núcleo para fora dele. Ao mesmo tempo, os projetos estão exportando cada vez mais interfaces de baixo nível, de forma a dotar os programadores de recursos para construir aplicações que possam implementar políticas específicas utilizando library operating systems implementados ao nível de usuário
(HULSE e DEARLE,1998).
Há, portanto, diferentes abordagens para a construção de núcleos de sistemas operacionais. Todas elas possuem pontos fortes e pontos fracos, tornando-as mais adequadas para propósitos e equipamentos específicos. Estas questões estão presentes tanto em sistemas comerciais tradicionais de propósitos gerais, como em comerciais dedicados (ou embarcados – embedded) e até mesmo em sistemas de pesquisa.
No entanto, apesar de finalidades aparentemente diferentes e em algumas situações com requisitos conflitantes, invariavelmente as propostas recaem sobre a definição apresentada inicialmente, ou seja: um componente de software que se pretende que venha a controlar o hardware e o torne disponível ao usuário. A Tabela 18(Pág.91) apresenta as principais características destes projetos.
Segundo Mosberger(1997),
“Apesar dos avanços tecnológicos experimentados nos últimos tempos, particularmente na última década, a estrutura fundamental dos sistemas operacionais tem permanecido invariavelmente a mesma”. E ele continua: “A luz de eventos recentes como, por exemplo, a popularização da internet, é razoável questionar se o enfoque em computação (computing) é aceitável. A recente ênfase em interligação de equipamentos (networking) pode indicar que o enfoque em comunicação (communicating) pode logo vir a se tornar à razão de ser dos computadores”.
Acrescente-se a esta afirmação toda a discussão sobre computação ubíqua apresentada no capítulo 3(Pág.94).
À medida que a evolução tecnológica produz hardware mais rápido e com mais recursos, surgem novas necessidades em termos de software e, à medida que estas facilidades são incorporadas “ao sistema”, os usuários tornam-se cada vez mais exigentes, o que conduz a um círculo vicioso. Naturalmente, à medida que novas facilidades são disponibilizadas ao usuário, novos recursos são agregados ao núcleo do sistema operacional, ou novas aplicações de suporte fazem-se necessárias para que elas a funcionem adequadamente.
Kon(2000)afirma que,
“Os sistemas atuais não são projetados para adaptarem-se rapidamente a mudanças ambientais tais como: atualizações de software e hardware e, flutuações na carga de processador e banda de rede disponível. Não há um mecanismo que permita a inserção de componentes auto-adaptáveis que possam otimizar a performance do sistema de acordo com as diversidades acima comentadas”.
Para atender a esta demanda cada vez maior por suporte a novos recursos, a tendência dos projetistas de sistemas operacionais tem sido a de desenvolver sistemas cada vez mais genéricos. Nicol et al.(1989) afirmam que este enfoque não é satisfatório por 2 razões principais:
• A funcionalidade é limitada por restrições ou generalizações inapropriadas, tendo em vista a abrangência necessária; e
• Ocorre redução na performance do sistema, uma vez que os recursos são ajustados para a maior possibilidade de uso e não para a melhor.
Em Beos (1998) são relacionadas algumas das suposições para que os sistemas operacionais atuais apresentem tais deficiências. São elas:
• Modelo monoprocessador: a arquitetura dos PCs atuais foi projetada há cerca de duas décadas atrás, época em que o custo dos microprocessadores era alto; hoje eles são commodities. No entanto, ainda são usados sistemas operacionais que podem ser executados em somente um processador.
• Tratamento de mídia digital: muitas das necessidades requeridas hoje em termos de mídia digital (imagens, sons, internet e outros), eram talvez consideradas em teoria quando os atuais sistemas foram projetados. Em conseqüência, sua arquitetura não possui a funcionalidade necessária para tratá-las adequadamente. Ou seja, a indústria está tentando liberar soluções para a próxima década usando arquiteturas projetadas para resolver problemas da década passada.
• Compatibilidade: a cada ano, os avanços de hardware melhoram significativamente a velocidade e reduzem custo dos processadores e periféricos. No entanto, o usuário final somente percebe uma fração dos recursos liberados a cada nova versão de hardware, em função da questão de compatibilidade binária com versões anteriores.
Neste sentido, Hydari(1999)afirma que o crescimento da Internet tem permitido um
nível de conectividade entre computadores que atinge um nível de onipresença. Mas este progresso tem gerado um determinado número de problemas que não são adequadamente tratados pelos atuais sistemas operacionais disponíveis. São eles:
• Utilização de um grupo de máquinas para execução de computação distribuída; • Migração de dados, computação e usuários;
• Manutenção e atualização de software, dependências entre componentes e portabilidade; • Flexibilidade de Crescimento (Scalability);
• Confiabilidade de sistemas de software; • Administração distribuída do sistema; • Segurança.
Assim sendo, o que se observa é que o sistema operacional, apesar de sua importância fundamental, não consegue acompanhar a evolução tecnológica, pelo menos na velocidade em que ela ocorre. Em função disto, à medida que surgem soluções temporárias, novas fontes de instabilidade são agregadas ao conjunto de problemas potenciais a que o usuário está sujeito.
A seguir são discutidos aspectos específicos relativos à confiabilidade e segurança dos dados armazenados em um computador, considerando-se as demandas identificadas no capítulo 3(Pág.94).