Um sistema tão grande e complexo quanto um sistema operacional moderno deve ser cuidadosamente cons- truído para que funcione bem e possa ser facilmente modificado. Uma abordagem comum é dividir a tarefa
Estruturas de Sistemas Operacionais • 47 cm pequenos componentes cm vez de ter um sistema monolítico/Cada um desses módulos deve ser uma por- ção bem delineada do sistema, com entradas, saídas e funções cuidadosamente definidas. Já discutimos rapi- damente os componentes comuns dos sistemas operacionais (Seção 3.1). Nesta seção, vamos discutir como esses componentes são interconectados e combinados no kernel.
3 . 5 . 1 E s t r u t u r a s i m p l e s
Existem vários sistemas comerciais que não possuem uma estrutura bem definida. Frequentemente, tais siste- mas operacionais começaram como sistemas pequenos, simples e limitados, crescendo alem do seu escopo original. O MS-DOS é um exemplo de um sistema assim. Foi originalmente projetado e implementado por algumas pessoas que não tinham ideia de que ele se tornaria tão popular. Foi escrito para fornecer funcionali- dade máxima no menor espaço possível (por causa do hardware limitado no qual era executado), por isso ele não foi dividido cuidadosamente em módulos. A Figura 3.6 mostra sua estrutura.
No MS-DOS, as interfaces e níveis de funcionalidade não são bem separados. Por exemplo, os programas aplicativos podem acessar as rotinas básicas de l/O para escrever dirctamente na tela e nas unidades de disco. Tal liberdade deixa o MS-DOS vulnerável a programas errantes (ou maliciosos), causando falhas no sistema inteiro quando os programas de usuário falham. È claro, o MS-DOS também foi limitado pelo hardware da época. Como o Intel 8088 para o qual o sistema foi escrito não fornece modo dual nem proteção de hardwa- re, os projetistas do MS-DOS não tiveram opção a não ser deixar o hardware de base acessível.
Outro exemplo de estruturação limitada é o sistema operacional UNIX original. O UNIX é outro sistema que inicialmente era limitado pela funcionalidade de hardware. Consiste em duas partes separáveis: o kernel e os programas de sistema. O kernel é separado ainda em uma série de interfaces e drivers de dispositivo, que foram adicionados e expandidos ao longo dos anos, à medida que o UNIX evoluiu. Podemos considerar o sis- tema operacional UNIX tradicional como sendo em camadas, como mostrado na Figura 3.7. Tudo o que está abaixo da interface de chamadas ao sistema e acima do hardware físico é o kernel. O kernel fornece sistema de arquivos, escalonamento de CPU, gerência de memória e outras funções de sistema operacional através de chamadas ao sistema. Somando tudo, significa muita funcionalidade a ser combinada em um nível. Os pro- gramas de sistema usam as chamadas de sistema suportadas pelo kernel para fornecer funções úteis, tais como compilação e manipulação de arquivos.
programa de sistema residente
Figura 3.6 Estrutura cm camadas do MS-DOS.
As chamadas ao sistema definem a interface de programação de aplicações (Application Programing Interface- API) para o UNIX; o conjunto de programas de sistema normalmente disponíveis define a interfa- ce de usuário. As interfaces de programador e de usuário definem o contexto que o kernel deve suportar.
Novas versões do UNIX são projetadas para usar hardware mais avançado. Com suporte de hardware adequado, os sistemas operacionais podem ser divididos em partes menores e mais apropriadas do que aque- las permitidas pelos sistemas MS-DOS ou UNIX originais. O sistema operacional pode reter muito mais con- trole do computador e dos aplicativos que utilizam o computador. Os implementadores têm maior liberdade
48 • Sistemas Operacionais
para fazer alterações nas funções internas do sistema c na criação de sistemas operacionais modulares. Nessa abordagem top-down, a funcionalidade e os recursos gerais são determinados e separados em componentes. Ocultar informações também é importante, porque deixa os programadores livres para implementar rotinas de baixo nível conforme a necessidade, desde que a interface externa da rotina fique inalterada e que a rotina em si execute a tarefa como especificado.
(os usuários)
sheiís e comandos compiladores e interpretadores
bibliotecas do sistema
interface de chamada ao sistema para o kornel
tratamento de sinal de terminal sistema de l/O de caracteres drivers de terminal sistema de arquivos swappino, sistema de l/O de Moco drivers de disco e fria
interface do komei com o hardwaie
escalonamento de CPU substituição de página paginação por demanda
memória virtual controladoras de terminal terminais controladoras de dispositivo discos e fitas controladoras de memória memoria física
Figura 3.7 Estrutura do sistema UNIX.
3.5.2 Abordagem em camadas
A modularização de um sistema pode ser feita de muitas formas; um método é a abordagem em camadas, na qual o sistema operacional é dividido cm uma série de camadas (níveis), cada qual construída sobre ca- madas inferiores. A camada inferior (camada 0) é o hardware; a camada superior (camada N) é a interface de usuário.
Uma camada de sistema operacional e" uma implementação de um objeto abstraio que é o encapsulamen- to de dados e das operações que podem manipular esses dados. Uma camada típica de um sistema operacio- nal - digamos a camada M-é representada na Figura 3.8. Ela consiste em estruturas de dados e um conjunto de rotinas que podem ser chamadas por camadas de nível mais alto. A camada M, por sua vez, pode chamar operações cm camadas de níveis mais baixos.
A principal vantagem da abordagem em camadas é a modularidade. As camadas são selecionadas de for- ma que cada uma utilize as funções (operações) e serviços apenas das camadas de nível mais baixo. Essa abor- dagem simplifica a depuração e a verificação do sistema. A primeira camada pode ser depurada sem preocu- pação com o resto do sistema, porque, por definição, ela só utiliza 0 hardware básico (que é considerado correio) para implementar suas funções. Depois que a primeira camada c depurada, pode-se presumir seu funcionamento correto enquanto a segunda camada é depurada e assim por diante. Se for encontrado um erro durante a depuração de determinada camada, o erro deve estar nessa camada, porque as camadas inferi- ores já foram depuradas. Assim, o projeto e a implementação do sistema são simplificados quando o sistema é dividido em camadas.
Cada camada é implementada apenas com as operações fornecidas pelas camadas de nível inferior. Uma camada não precisa saber como essas operações são implementadas; só precisa saber o que essas operações fazem. Portanto, cada camada oculta a existência de determinadas estruturas de dados, operações e hardware de camadas de nível mais alto.
A principal dificuldade da abordagem cm camadas está na definição adequada das várias camadas. Como uma camada só pode usar as camadas que estão em um nível inferior, é preciso haver um planejamento cuida- doso. Por exemplo, o driver de dispositivo para o armazenamento auxiliar (espaço em disco usado por algo- ritmos de memória virtual) deve estar em um nível abaixo das rotinas de gerência de memória, porque a ge- rência de memória requer a capacidade de usar o armazenamento auxiliar.