Você está na página 1de 10

GOVERNO DO ESTADO DO RIO DE JANEIRO FUNDAO DE APOIO A ESCOLA TCNICA ESCOLA TCNICA ESTADUAL REPBLICA

SO
Sistemas Operacionais
___________________________

Curso de Informtica

ETE REPBLICA - Rua Clarimundo de Melo, 847, Quintino Bocaiva Rio de Janeiro

4
ESTRUTURA DO SISTEMA OPERACIONAL
4.1 Introduo
O sistema operacional formado por um conjunto de rotinas que oferecem servios aos usurios, s suas aplicaes, e tambm ao prprio sistema. Esse conjunto de rotinas denominado ncleo do sistema ou kernel. importante no confundir o ncleo do sistema com aplicaes, utilitrios ou o interpretador de comandos, que acompanham o sistema operacional (Fig.4.1). As aplicaes so utilizadas pelos usurios e escondem todos os detalhes da interao com o sistema. Os utilitrios, como compiladores e editores de texto, e interpretadores de comandos permitem aos usurios, administradores e desenvolvedores uma interao amigvel com o sistema. Existe uma grande dificuldade em compreender a estrutura e o funcionamento de um sistema operacional, pois ele no executado como uma aplicao tipicamente seqencial, com inicio, meio e fim. Os procedimentos do sistema so executados concorrentemente sem uma ordem predefinida, com base em eventos dissociados do tempo (eventos assncronos). Muitos desses eventos esto relacionados ao hardware e a tarefas internas do prprio sistema operacional. As principais funes do ncleo encontradas na maioria dos sistemas comerciais esto listadas a seguir. No decorrer do livro, estaremos abordando estas funes e detalhes: m tratamento de interrupes e excees; criao e eliminao de processos e threads; sincronizao e comunicao entre processos e threads; escalonamento e controle dos processos e threads; gerncia de memria; gerncia do sistema de arquivos; gerncia de dispositivos de E/S; Fig. 4.1 Sistema computacional suporte a redes locais e distribudas; contabilizao do uso do sistema; auditoria e segurana do sistema.

A estrutura do sistema operacional, ou seja, a maneira corno o cdigo do sistema organizado e o inter-relacionamento entre seus diversos componentes, pode variar conforme a concepo do projeto. Existem diversas abordagens em relao estrutura de sistemas operacionais que sero tratadas no decorrer do capitulo. Inicialmente sero apresentados os conceitos de system calls e do mecanismo de modos de acesso.

4.2 System Calls


Uma preocupao que surge nos projetos de sistemas operacionais e a implementao de mecanismos de proteo ao ncleo do sistema e de acesso aos seus servios. Caso uma aplicao que tenha acesso ao ncleo realize uma operao que altere sua integridade, todo o sistema poder ficar comprometido e inoperante. As svstem calls podem ser entendidas como uma porta de entrada para o acesso ao ncleo do sistema operacional e a seus servios. Sempre que um usurio ou aplicao desejar algum servio do sistema, realizada uma chamada a uma de suas rotinas atravs de uma svstem call (chamada ao sistema). O termo system call tipicamente utilizado em sistemas Unix, porm em outros sistemas o mesmo conceito apresentado com diferentes nomes, como systern services no Open VMS e Application Program Interface (API) no Windows da Microsoft. Para cada servio disponvel existe uma system call associada e cada sistema operacional tem seu prprio conjunto de chamadas, com nomes. parmetros e formas de ativao especficos Fig. 4.2). Isto explica por que uma aplicao desenvolvida utilizando servios de um determinado sistema operacional no pode ser podada diretamente para um outro sistema.

Fig. 4.2 System call. Uma tentativa de criar uma biblioteca de chamada.s padronizadas foi proposta pelos institutos ISO e IEEE. O padro POSIX (Portable Operating System Interface for Unix), como foi definido, permitiu que uma aplicao desenvolvida seguindo este conjunto de chamadas pudesse ser executada em qualquer sistema operacional que oferecesse suporte ao padro. Inicialmente voltado para a unificao das diversas verses do sistema Unix, o POSIX foi incorporado, posteriormente, pela maioria dos sistemas operacionais modernos. Atravs dos parmetros fornecidos na system call, a solicitao processada e uma resposta retornada aplicao juntamente com um estado de concluso indicando se houve algum erro. O mecanismo de ativao e comunicao entre o programa e o sistema operacional semelhante ao mecanismo implementado quando um programa chama uma sub-rotina. As system calls podem ser divididas por grupos de funco (Tabela 4.1). A maioria dos programadores e usurios desconhece os detalhes envolvidos, por exemplo, em um simples comando de leitura a um arquivo utilizando uma linguagem de alto nvel. De forma simplificada, o comando da linguagem de alto nvel convertido pelo compilador para uma chamada

a uma svstem call especifica, que, quando executada, verifica a ocorrncia de erros e retorna os dados ao programa de forma transparente ao usurio.

4.3 Modos de Acesso


Existem certas instrues que no podem ser colocadas diretamente disposio das aplicaes, pois a sua utilizao indevida ocasionaria srios problemas integridade do sistema. Suponha que uma aplicao atualize um arquivo em disco. O programa, por si s no pode especificar diretamente as instrues que acessam seus dados no disco. Como o disco um recurso compartilhado, sua utilizao dever ser gerenciada unicamente pelo sistema operacional, evitando que a aplicao possa ter acesso a qualquer rea do disco indiscriminadamente. O que poderia comprometer a segurana e integridade do sistema de arquivos. Tabela 4.1 Funes das system call Funes Gerncia de processos e threads System calls Criao e eliminao de processos e threads Alterao das caractersticas de processos e threads Sincronizao e comunicao entre processos e threads Obteno de informaes sobre processos e threads Alocao e desalocao de memria Criao e eliminao de arquivos e diretrios Alterao das caractersticas de arquivos e diretrios Abrir e fechar arquivos Leitura e gravao em arquivos Obteno de informaes sobre arquivos e diretrios Alocao e desalocao de dispositivos Operaes de entrada/sada em dispositivos Obteno de informaes sobre dispositivos

Gerncia de memria Gerncia do sistema de arquivos

Gerencia de dispositivos

Como visto, fica claro que existem certas instrues que s devem ser executadas pelo sistema operacional ou sob sua superviso, impedindo, assim a ocorrncia de problemas de segurana e integridade do sistema. As instrues que tm o poder de comprometer o sistema so conhecidas como instrues privilegiadas, enquanto as instrues no privilegiadas so as que no oferecem risco ao sistema. Para que uma aplicao possa executar uma instruo privilegiada, necessrio que no processador seja implementado o mecanismo de proteo conhecido como modos de acesso. Existem. basicamente, dois modos de acesso implementados pelos processadores: modo usurio e modo kernel. Quando o processador trabalha no modo usurio, uma aplicao s pode executar instrues noprivilegiadas, tendo acesso a um nmero reduzido de instrues, enquanto no modo kernel ou supervisor a aplicao pode ter acesso ao conjunto total de instrues do processador. O modo de acesso de uma aplicao determinado por um conjunto de bits localizado no registrador de status do processador, ou PSW, que indica o modo de acesso corrente. Atravs desse registrador, o hardware verifica se a instruo pode ou no ser executada pela aplicao.

A melhor maneira de controlar o acesso as instrues privilegiadas permitir que apenas o sistema operacional tenha acesso a elas. Sempre que uma aplicao necessita executar uma instruo privilegiada, a solicitao deve ser realizada atravs de uma chamada a uma system call, que altera o modo de acesso do processador do modo usurio para o modo kernel. Ao trmino da execuo da rotina do sistema, o modo de acesso retorna para o modo usurio (fig. 4.3). Caso uma aplicao tente executar uma instruo privilegiada diretamente em modo usurio, o processador sinalizar um erro, uma exceo gerada e a execuo do programa interrompida. Utilizando o mesmo problema do acesso ao disco apresentado, para o programa atualizar um arquivo em disco a aplicao deve solicitar a operao de E/S ao sistema operacional por meio de uma system call, que altera o modo de acesso do processador de usurio para kernel. Aps executar a rotina de leitura, o modo de acesso volta ao estado usurio para continuar a execuo do programa. O mecanismo de modos de acesso tambm uma boa forma de proteger o prprio ncleo do sistema residente na memria principal. Suponha que uma aplicao tenha acesso a reas de memria onde est o sistema operacional. Qualquer programador malintencionado ou um erro de programao poderia gravar nesta rea, violando o sistema. Com o mecanismo de modos de acesso, para uma aplicao escrever numa rea onde resida o sistema operacional o programa deve estar sendo executado no modo kernel.

Fig. 4.3 Chamada a uma rotina do sistema

4.4 Arquitetura Monoltica


A arquitetura monoltica pode ser comparada com uma aplicao formada por vrios mdulos que so compilados separadamente e depois linkados, formando um grande e nico programa executvel, onde os mdulos podem interagir livremente. Os primeiros sistemas operacionais foram desenvolvidos com base neste modelo, o que tornava seu desenvolvimento e, principalmente, sua manuteno bastante difceis. Devido a sua simplicidade e bom desempenho, a estrutura monoltica foi adotada no projeto do MS-DOS e nos primeiros sistemas Unix.

4.5 Arquitetura de Camadas


Com o aumento da complexidade e do tamanho do cdigo dos sistemas operacionais, tcnicas de programao estruturada e modular foram incorporadas ao seu projeto. Na arquitetura de camadas, o

sistema dividido em nveis sobrepostos. Cada camada oferece um conj unto de funes que podem ser utilizadas apenas pelas camadas superiores. O primeiro sistema com base nesta abordagem foi o sistema THE (Technische Hogeschool Eindhoven), construdo por Dijkstra, na Holanda, em 1968, e que utilizava seis camadas. Posteriormente, os sistemas MULTICS e Open VMS tambm implementaram o conceito de camadas, sendo estas concntricas (Fig.4.5). Neste tipo de implementao, as camadas mais internas so mais privilegiadas que as mais externas. A vantagem da estruturao em camadas isolar as funes do sistema operacional, facilitando sua manuteno e depurao, alm de criar uma hierarquia de nveis de modos de acesso, protegendo as camadas mais internas. Uma desvantagem para o modelo de camadas o desempenho. Cada nova camada implica uma mudana no modo de acesso. Por exemplo, no caso do Open VMS, para se ter acesso aos servios oferecidos pelo kernel preciso passar por trs camadas ou trs mudanas no modo de acesso. Atualmente, a maioria dos sistemas comerciais utiliza o modelo de duas camadas, onde existem os modos de acesso usurio (no-privilegiado) e kernel (privilegiado). A maioria das verses do Unix e do Windows 2000 da Microsoft esto baseados neste modelo.

Fig 4.4 Arquitetura monoltica.

Fig 4.5 Arquitetura em camada do OpenVMS

4.6 Mquina Virtual


Um sistema computacional formado por nveis, onde a camada de uiveI mais baixo o hardware. Acima desta camada encontramos o sistema operacional, que oferece suporte para as aplicaes, como visto na Fig. 4.1. O modelo de mquina virtual, ou virtual machine (VM), cria um nvel intermedirio entre o hardware e o sistema operacional, denominado gerncia de mquinas virtuais

(Fig. 4.6). Este nvel cria diversas maquinas virtuais independentes, onde cada unia oferece uma cpia virtual do hardware, incluindo os modos de acesso, interrupes, dispositivos de E/S etc. Como cada mquina virtual independente tias demais, possvel que cada VM tenha seu prprio sistema operacional e que seus usurios executem suas aplicaes como se todo o computador estivesse dedicado a cada um deles. Na dcada de 1960, a IBM implementou este modelo no sistema VM/370, permitindo que aplicaes batch, originadas de antigos sistemas OS/360, e aplicaes de tempo compartilhado pudessem conviver na mesma mquina de forma transparente a seus usurios e aplicaes. Alm de permitir a convivncia de sistemas operacionais diferentes no mesmo computador, este modelo cria o isolamento total entre cada VM, oferecendo grande segurana para cada mquina virtual. Se, por exemplo, uma VM executar uma aplicao que comprometa o funcionamento do seu sistema operacional, as demais mquinas virtuais no sofrero qualquer problema. A desvantagem desta arquitetura a sua grande complexidade, devido necessidade de se compartilhar e gerenciar os recursos do hardware entre as diversas VMs. Outro exemplo de utilizao desta arquitetura ocorre na linguagem Java, desenvolvida pela Sun Microsystems. Para se executar um programa um programa necessario uma mquina virtual Java (Java Virtual Machine JVM). Qualquer sistema operacional pode suportar urna aplicao Java. desde que exista urna JVM desenvolvida para ele. Desta forma, a aplicao no precisa ser recompilada para cada sistema computacional. tornando-se independente do hardware e sistema operacional utilizados (Fig. 4.7). A desvantagem deste modelo o seu menor desempenho se comparado a uma aplicao compilada e executada diretamente em urna arquitetura especifica. Fig. 4.6 Mquina Virtual.

4.7 Arquitetura Microkernel


Uma tendncia nos sistemas operacionais modernos tomar o ncleo do sistema operacional o menor e mais simples possvel. Para implementar esta idia, os servios do sistema so disponibilizados atravs de processos, onde cada um responsvel por oferecer um conjunto especfico de funes, como gerncia de arquivos. gerncia de processos, gerncia de memria e escalonamento. Sempre que uma aplicao deseja algum servio, realizada urna solicitao ao processo responsvel. Neste caso, a aplicao que solicita o servio chamada de cliente, enquanto o processo que responde solicitao chamado de servidor. Um cliente, que pode ser uma aplicao de um usurio ou um outro componente do sistema operacional. solicita um servio enviando urna mensagem para o servidor O servidor responde ao cliente atravs de urna outra mensagem. A principal funo do ncleo realizar a comunicao, ou sela, a troca de mensagens entre cliente e servidor (Fig. 4.8).

O conceito de arquitetura microkernel surgiu no sistema operacional Mach, na dcada de 1980, na Universidade Carnegie-Mellon. O ncleo do sistema Mach oferece basicamente quatro servios: gerncia de processos, gerncia de memria, comunicao por troca de mensagens e operaes de E/S, todos em modo usurio. A utilizao deste modelo permite que os servidores executem em modo usurio, ou seja, no tenham acesso direto a certos componentes do sistema. Apenas o ncleo do sistema, responsvel pela comunicao entre clientes e servidores, executa no modo kernel. Como conseqncia, se ocorrer um erro em um servidor, este poder parar, mas o sistema no ficar inteiramente comprometido, aumentando assim a sua disponibilidade. Como os servidores se comunicam atravs de trocas de mensagens, no importa se os clientes e servidores so processados em um sistema com um nico processador, com mltiplos processadores (fortemente acoplado) ou ainda em um ambiente de sistema distribudo (fracamente acoplado). A implementao de sistemas microkernel em ambientes distribudos permite que um cliente solicite um servio e a resposta sela processada remotamente. Esta caracterstica permite acrescentar novos servidores medida que o nmero de clientes aLimenta, conferindo uma grande escalabilidade ao sistema operacional. Alm disso. a arquitetura microkernel permite isolar as funes do sistema operacional por diversos processos servidores pequenos e dedicados a servios especficos, tomando o ncleo menor, mais fcil de depurar e, conseqentemente, aumentando sua confiabilidade. Na arquitetura microkernel, o sistema operacional passa a ser de mais fcil manuteno, flexvel e de maior portabilidade. Apesar de todas as vantagens deste modelo, sua implementao, na prtica, muito difcil. Primeiro existe o problema de desempenho, devido necessidade de mudana de modo de acesso a cada comunicao entre clientes e servidores. Outro problema e que cenas funes do sistema operacional exigem acesso direto ao hardware, como operaes de E/S. Na realidade, o que implementado mais usualmente uma combinao do modelo de camadas com a arquitetura microkernel. O ncleo do sistema, alm de ser responsvel pela comunicao entre cliente e servidor, passa a incorporar outras funes crticas do sistema, como escalonamento, tratamento de interrupes e gerncia de dispositivos.

Fig. 4.7 mquina Virtual Java

Existem vrios projetos baseados em sistemas microkernel, principalmente em instituies de ensino e centros de pesquisa, como o Exokernel, do MIT (Massachusetts Institute of Technology); o L4, da Universidade de Dresden; e o Amoeba, da Vrije Universiteir. A maioria das iniciativas nesta rea est relacionada ao desenvolvimento de sistemas operacionais distribudos.

4.8 Projeto do Sistema


O projeto de um sistema operacional bastante complexo e deve atender a diversos requisitos, algumas vezes conflitantes, como confiabilidade, portabilidade, manutenibilidade, flexibilidade e desempenho. O projeto do sistema ira depender muito da arqtiitetura cIo hardware a ser utilizado e do tipo de sistema que se deseja construir: batch, tempo compartilhado, monousuario ou multusurio, tempo real etc. i Os primeiros sistemas operacionais foram desenvolvidos integralmente em assembly e o cdigo possua cerca de um milho de instrues (IBM OS/360). Com a evoluo dos sistemas e o aumento do nmero de linhas de cdigo para algo perto de 20 milhes (MULTICS), tcnicas de programao modular foram incorporadas ao projeto, alm de linguagens de alto nvel, como PL/I e Algol. Nos sistemas operacionais atuais, o nmero de linhas de cdigo pode chegar a mais de 40 milhes (Windows 2000), sendo grande parte do cdigo escrita em linguagem C/C++, utilizando em alguns casos programao orientada a objetos. Urna tendncia no projeto de sistemas operacionais modernos a utilizao de tcnicas de orientao por objetos, o que leva para o projeto do ncleo do sistema todas as vantagens deste modelo de desenvolvimento de software. Existe uma srie de vantagens na utilizao de programao por objetos no projeto e na implementao de sistemas operacionais. A seguir, os principais beneficios so apresentados: melhoria ria organizao das funes e recursos do sistema; reduo no tempo de desenvolvimento; maior facilidade na manuteno e extenso do sistema; facilidade de implementao do modelo de computao distribuda.

Alm de facilitar o desenvolvimento e a manuteno do sistema, a utilizao de linguagens de alto nvel permite maior portabilidade, ou seja, que o sistema operacional seja facilmente alterado em outra arquitetura de hardware. Uma desvantagem do uso de linguagens de alto nvel em relao programao assembly a perda de desempenho. Por isto, as partes criticas do sistema, corno os device drivers, o escalonador e as rotinas de tratamento de interrupes, so desenvolvidas em assembly. Um importante princpio no projeto de sistemas operacionais a separao no projeto do sistema das polticas e dos mecanismos. Uma poltica define o que deve ser feito, enquanto um mecanismo define como implementar uma determinada poltica.

4.9 Exerccios
1. O que o ncleo do sistema e quais so suas principais funes? 2. O que uma system call e qual sua importncia para a segurana do sistema? Como as system calls so utilizadas por um programa? 3. O que so instrues privilegiadas e no-privilegiadas? Qual a relao dessas instrues com os modos de acesso? 4. Quais das instrues a seguir devem ser executadas apenas em modo kernel? Desabilitar todas as interrupes, consultar a data e hora do sistema. alterar a data e hora do sistema, alterar informaes residentes no ncleo do sistema, somar duas variveis declaradas dentro do programa, realizar um desvio para uma instruo dentro do prprio programa e acessar diretamente posies no disco. 5. Explique como funciona a mudana de modos de acesso e d um exemplo de corno um programa faz uso desse mecanismo. 6. Como o kernel do sistema operacional pode ser protegido pelo mecanismo de modos de acesso? 7. Compare as arquiteturas monoltica e de camadas. Quais as vantagens e desvantagens de cada arquitetura? 8. Quais as vantagens do modelo de mquina virtual? 9. Como funciona o modelo clienteservidor na arquitetura microkernel? Quais so as vantagens e desvantagens dessa arquitetura? 10. Por que a utilizao da programao orientada a objetos um caminho natura] para o projeto de sistemas operacionais?