Sistemas Operacionais: Conceitos e Mecanismos I - Conceitos Bsicos

Prof. Carlos Alberto Maziero DAInf UTFPR http://dainf.ct.utfpr.edu.br/maziero 2 de junho de 2013

Este texto est licenciado sob a Licena Attribution-NonCommercial-ShareAlike 3.0 Unported da Creative Commons (CC). Em resumo, voc deve creditar a obra da forma especicada pelo autor ou licenciante (mas no de maneira que sugira que estes concedem qualquer aval a voc ou ao seu uso da obra). Voc no pode usar esta obra para ns comerciais. Se voc alterar, transformar ou criar com base nesta obra, voc poder distribuir a obra resultante apenas sob a mesma licena, ou sob uma licena similar presente. Para ver uma cpia desta licena, visite http://creativecommons.org/licenses/by-nc-sa/3.0/. Este texto foi produzido usando exclusivamente software livre: Sistema Operacional GNU/Linux (distriA buies Fedora e Ubuntu), compilador de texto L TEX 2 , gerenciador de referncias BibTeX, editor grco Inkscape, criadores de grcos GNUPlot e GraphViz e processador PS/PDF GhostScript, entre outros.

c Carlos Maziero

: SUMRIO

Sumrio
1 Objetivos 1.1 Abstrao de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Gerncia de recursos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tipos de sistemas operacionais Funcionalidades Estrutura de um sistema operacional Conceitos de hardware 5.1 Interrupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Proteo do ncleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Chamadas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Arquiteturas de Sistemas Operacionais 6.1 Sistemas monolticos . . . . . . . . 6.2 Sistemas em camadas . . . . . . . . 6.3 Sistemas micro-ncleo . . . . . . . 6.4 Mquinas virtuais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3 5 6 7 10 11 12 15 17 19 19 20 21 22 26

2 3 4 5

Um breve histrico dos sistemas operacionais

c Carlos Maziero

: Objetivos

Resumo Um sistema de computao constitudo basicamente por hardware e software. O hardware composto por circuitos eletrnicos (processador, memria, portas de entrada/sada, etc.) e perifricos eletro-ptico-mecnicos (teclados, mouses, discos rgidos, unidades de disquete, CD ou DVD, dispositivos USB, etc.). Por sua vez, o software de aplicao representado por programas destinados ao usurio do sistema, que constituem a razo nal de seu uso, como editores de texto, navegadores Internet ou jogos. Entre os aplicativos e o hardware reside uma camada de software multi-facetada e complexa, denominada genericamente de Sistema Operacional. Neste captulo veremos quais os objetivos bsicos do sistema operacional, quais desaos ele deve resolver e como ele estruturado para alcanar seus objetivos.

Objetivos

Existe uma grande distncia entre os circuitos eletrnicos e dispositivos de hardware e os programas aplicativos em software. Os circuitos so complexos, acessados atravs de interfaces de baixo nvel (geralmente usando as portas de entrada/sada do processador) e muitas vezes suas caractersticas e seu comportamento dependem da tecnologia usada em sua construo. Por exemplo, a forma de acesso de baixo nvel a discos rgidos IDE difere da forma de acesso a discos SCSI ou leitores de CD. Essa grande diversidade pode ser uma fonte de dores de cabea para o desenvolvedor de aplicativos. Portanto, torna-se desejvel oferecer aos programas aplicativos uma forma de acesso homognea aos dispositivos fsicos, que permita abstrair as diferenas tecnolgicas entre eles. O sistema operacional uma camada de software que opera entre o hardware e os programas aplicativos voltados ao usurio nal. O sistema operacional uma estrutura de software ampla, muitas vezes complexa, que incorpora aspectos de baixo nvel (como drivers de dispositivos e gerncia de memria fsica) e de alto nvel (como programas utilitrios e a prpria interface grca). A Figura 1 ilustra a arquitetura geral de um sistema de computao tpico. Nela, podemos observar elementos de hardware, o sistema operacional e alguns programas aplicativos. Os objetivos bsicos de um sistema operacional podem ser sintetizados em duas palavras-chave: abstrao e gerncia, cujos principais aspectos so detalhados a seguir.

1.1

Abstrao de recursos

Acessar os recursos de hardware de um sistema de computao pode ser uma tarefa complexa, devido s caractersticas especcas de cada dispositivo fsico e a complexidade de suas interfaces. Por exemplo, a sequncia a seguir apresenta os principais passos envolvidos na abertura de um arquivo (operao open) em um leitor de disquete: 1. vericar se os parmetros informados esto corretos (nome do arquivo, identicador do leitor de disquete, buer de leitura, etc.); 3

c Carlos Maziero
editor de textos
Ad augusta per angusta. De omni re scibili, et quibusdam aliis. Felix qui potuit rerum cognoscere causas. In medio stat virtus. Labor omnia vincit improbus. Non nova, sed nove. Qui scribit bis legit.

: Abstrao de recursos
reprodutor de mdia
c

editor grco

aplicativos

sistema operacional

hardware

discos

memria

portas USB

rede

Figura 1: Estrutura de um sistema de computao tpico 2. vericar se o leitor de disquetes est disponvel; 3. vericar se o leitor contm um disquete; 4. ligar o motor do leitor e aguardar atingir a velocidade de rotao correta; 5. posicionar a cabea de leitura sobre a trilha onde est a tabela de diretrio; 6. ler a tabela de diretrio e localizar o arquivo ou subdiretrio desejado; 7. mover a cabea de leitura para a posio do bloco inicial do arquivo; 8. ler o bloco inicial do arquivo e deposit-lo em um buer de memria. Assim, o sistema operacional deve denir interfaces abstratas para os recursos do hardware, visando atender os seguintes objetivos: Prover interfaces de acesso aos dispositivos, mais simples de usar que as interfaces de baixo nvel, para simplicar a construo de programas aplicativos. Por exemplo: para ler dados de um disco rgido, uma aplicao usa um conceito chamado arquivo, que implementa uma viso abstrata do disco rgido, acessvel atravs de operaes como open, read e close. Caso tivesse de acessar o disco diretamente, teria de manipular portas de entrada/sada e registradores com comandos para o controlador de disco (sem falar na diculdade de localizar os dados desejados dentro do disco). Tornar os aplicativos independentes do hardware. Ao denir uma interface abstrata de acesso a um dispositivo de hardware, o sistema operacional desacopla o hardware 4

c Carlos Maziero

: Gerncia de recursos

dos aplicativos e permite que ambos evoluam de forma mais autnoma. Por exemplo, o cdigo de um editor de textos no deve ser dependente da tecnologia de discos rgidos utilizada no sistema. Denir interfaces de acesso homogneas para dispositivos com tecnologias distintas. Atravs de suas abstraes, o sistema operacional permite aos aplicativos usar a mesma interface para dispositivos diversos. Por exemplo, um aplicativo acessa dados em disco atravs de arquivos e diretrios, sem precisar se preocupar com a estrutura real de armazenamento dos dados, que podem estar em um disquete, um disco IDE, uma mquina fotogrca digital conectada porta USB, um CD ou mesmo um disco remoto, compartilhado atravs da rede.

1.2

Gerncia de recursos

Os programas aplicativos usam o hardware para atingir seus objetivos: ler e armazenar dados, editar e imprimir documentos, navegar na Internet, tocar msica, etc. Em um sistema com vrias atividades simultneas, podem surgir conitos no uso do hardware, quando dois ou mais aplicativos precisam dos mesmos recursos para poder executar. Cabe ao sistema operacional denir polticas para gerenciar o uso dos recursos de hardware pelos aplicativos, e resolver eventuais disputas e conitos. Vejamos algumas situaes onde a gerncia de recursos do hardware se faz necessria: Cada computador normalmente possui menos processadores que o nmero de tarefas em execuo. Por isso, o uso desses processadores deve ser distribudo entre os aplicativos presentes no sistema, de forma que cada um deles possa executar na velocidade adequada para cumprir suas funes sem prejudicar os demais. O mesmo ocorre com a memria RAM, que deve ser distribuda de forma justa entre as aplicaes. A impressora um recurso cujo acesso deve ser efetuado de forma mutuamente exclusiva (apenas um aplicativo por vez), para no ocorrer mistura de contedo nos documentos impressos. O sistema operacional resolve essa questo denindo uma la de trabalhos a imprimir (print jobs) normalmente atendidos de forma sequencial (FIFO). Ataques de negao de servio (DoS Denial of Service) so comuns na Internet. Eles consistem em usar diversas tcnicas para forar um servidor de rede a dedicar seus recursos a atender um determinado usurio, em detrimento dos demais. Por exemplo, ao abrir milhares de conexes simultneas em um servidor de e-mail, um atacante pode reservar para si todos os recursos do servidor (processos, conexes de rede, memria e processador), fazendo com que os demais usurios no sejam mais atendidos. responsabilidade do sistema operacional do servidor detectar tais situaes e impedir que todos os recursos do sistema sejam monopolizados por um s usurio (ou um pequeno grupo). Assim, um sistema operacional visa abstrair o acesso e gerenciar os recursos de hardware, provendo aos aplicativos um ambiente de execuo abstrato, no qual o acesso 5

c Carlos Maziero

: Tipos de sistemas operacionais

aos recursos se faz atravs de interfaces simples, independentes das caractersticas e detalhes de baixo nvel, e no qual os conitos no uso do hardware so minimizados.

Tipos de sistemas operacionais

Os sistemas operacionais podem ser classicados segundo diversos parmetros e perspectivas, como tamanho, velocidade, suporte a recursos especcos, acesso rede, etc. A seguir so apresentados alguns tipos de sistemas operacionais usuais (muitos sistemas operacionais se encaixam bem em mais de uma das categorias apresentadas): Batch (de lote) : os sistemas operacionais mais antigos trabalhavam por lote, ou seja, todos os programas a executar eram colocados em uma la, com seus dados e demais informaes para a execuo. O processador recebia os programas e os processava sem interagir com os usurios, o que permitia um alto grau de utilizao do sistema. Atualmente, este conceito se aplica a sistemas que processam tarefas sem interao direta com os usurios, como os sistemas de processamento de transaes em bancos de dados. Alm disso, o termo em lote tambm usado para designar um conjunto de comandos que deve ser executado em sequncia, sem interferncia do usurio. Exemplos desses sistemas incluem o OS/360 e VMS, entre outros. De rede : um sistema operacional de rede deve possuir suporte operao em rede, ou seja, a capacidade de oferecer s aplicaes locais recursos que estejam localizados em outros computadores da rede, como arquivos e impressoras. Ele tambm deve disponibilizar seus recursos locais aos demais computadores, de forma controlada. A maioria dos sistemas operacionais atuais oferece esse tipo de funcionalidade. Distribudo : em um sistema operacional distribudo, os recursos de cada mquina esto disponveis globalmente, de forma transparente aos usurios. Ao lanar uma aplicao, o usurio interage com sua janela, mas no sabe onde ela est executando ou armazenando seus arquivos: o sistema quem decide, de forma transparente. Os sistemas operacionais distribudos j existem h tempos (Amoeba [Tanenbaum et al., 1991] e Clouds [Dasgupta et al., 1991], por exemplo), mas ainda no so uma realidade de mercado. Multi-usurio : um sistema operacional multi-usurio deve suportar a identicao do dono de cada recurso dentro do sistema (arquivos, processos, reas de memria, conexes de rede) e impor regras de controle de acesso para impedir o uso desses recursos por usurios no autorizados. Essa funcionalidade fundamental para a segurana dos sistemas operacionais de rede e distribudos. Grande parte dos sistemas atuais so multi-usurios. Desktop : um sistema operacional de mesa voltado ao atendimento do usurio domstico e corporativo para a realizao de atividades corriqueiras, como edio de textos e grcos, navegao na Internet e reproduo de mdias simples. Suas principais caractersticas so a interface grca, o suporte interatividade e a 6

c Carlos Maziero

: Funcionalidades

operao em rede. Exemplos de sistemas desktop so os vrios sistemas Windows (XP, Vista, 7, etc.), o MacOS X e Linux. Servidor : um sistema operacional servidor deve permitir a gesto eciente de grandes quantidades de recursos (disco, memria, processadores), impondo prioridades e limites sobre o uso dos recursos pelos usurios e seus aplicativos. Normalmente um sistema operacional servidor tambm tem suporte a rede e multi-usurios. Embarcado : um sistema operacional dito embarcado (embutido ou embedded) quando construdo para operar sobre um hardware com poucos recursos de processamento, armazenamento e energia. Aplicaes tpicas desse tipo de sistema aparecem em telefones celulares, sistemas de automao industrial e controladores automotivos, equipamentos eletrnicos de uso domstico (leitores de DVD, TVs, fornos-micro-ondas, centrais de alarme, etc.). Muitas vezes um sistema operacional embarcado se apresenta na forma de uma biblioteca a ser ligada ao programa da aplicao (que xa). LynxOS, C/OS, Xylinx e VxWorks so exemplos de sistemas operacionais embarcados para controle e automao. Sistemas operacionais para telefones celulares inteligentes (smartphones) incluem o Symbian e o Android, entre outros. Tempo real : ao contrrio da concepo usual, um sistema operacional de tempo real no precisa ser necessariamente ultra-rpido; sua caracterstica essencial ter um comportamento temporal previsvel (ou seja, seu tempo de resposta deve ser conhecido no melhor e pior caso de operao). A estrutura interna de um sistema operacional de tempo real deve ser construda de forma a minimizar esperas e latncias imprevisveis, como tempos de acesso a disco e sincronizaes excessivas. Existem duas classicaes de sistemas de tempo real: soft real-time systems, nos quais a perda de prazos implica na degradao do servio prestado. Um exemplo seria o suporte gravao de CDs ou reproduo de msicas. Caso o sistema se atrase, pode ocorrer a perda da mdia em gravao ou falhas na msica que est sendo tocada. Por outro lado, nos hard real-time systems a perda de prazos pelo sistema pode perturbar o objeto controlado, com graves consequncias humanas, econmicas ou ambientais. Exemplos desse tipo de sistema seriam o controle de funcionamento de uma turbina de avio a jato ou de uma caldeira industrial. Exemplos de sistemas de tempo real incluem o QNX, RT-Linux e VxWorks. Muitos sistemas embarcados tm caractersticas de tempo real, e vice-versa.

Funcionalidades

Para cumprir seus objetivos de abstrao e gerncia, o sistema operacional deve atuar em vrias frentes. Cada um dos recursos do sistema possui suas particularidades, o que impe exigncias especcas para gerenciar e abstrair os mesmos. Sob esta perspectiva, as principais funcionalidades implementadas por um sistema operacional tpico so: Gerncia do processador : tambm conhecida como gerncia de processos ou de atividades, esta funcionalidade visa distribuir a capacidade de processamento de 7

c Carlos Maziero

: Funcionalidades

forma justa1 entre as aplicaes, evitando que uma aplicao monopolize esse recurso e respeitando as prioridades dos usurios. O sistema operacional prov a iluso de que existe um processador independente para cada tarefa, o que facilita o trabalho dos programadores de aplicaes e permite a construo de sistemas mais interativos. Tambm faz parte da gerncia de atividades fornecer abstraes para sincronizar atividades inter-dependentes e prover formas de comunicao entre elas. Gerncia de memria : tem como objetivo fornecer a cada aplicao uma rea de memria prpria, independente e isolada das demais aplicaes e inclusive do ncleo do sistema. O isolamento das reas de memria das aplicaes melhora a estabilidade e segurana do sistema como um todo, pois impede aplicaes com erros (ou aplicaes maliciosas) de interferir no funcionamento das demais aplicaes. Alm disso, caso a memria RAM existente seja insuciente para as aplicaes, o sistema operacional pode aument-la de forma transparente s aplicaes, usando o espao disponvel em um meio de armazenamento secundrio (como um disco rgido). Uma importante abstrao construda pela gerncia de memria a noo de memria virtual, que desvincula os endereos de memria vistos por cada aplicao dos endereos acessados pelo processador na memria RAM. Com isso, uma aplicao pode ser carregada em qualquer posio livre da memria, sem que seu programador tenha de se preocupar com os endereos de memria onde ela ir executar. Gerncia de dispositivos : cada perifrico do computador possui suas peculiaridades; assim, o procedimento de interao com uma placa de rede completamente diferente da interao com um disco rgido SCSI. Todavia, existem muitos problemas e abordagens em comum para o acesso aos perifricos. Por exemplo, possvel criar uma abstrao nica para a maioria dos dispositivos de armazenamento como pen-drives, discos SCSI ou IDE, disquetes, etc., na forma de um vetor de blocos de dados. A funo da gerncia de dispositivos (tambm conhecida como gerncia de entrada/sada) implementar a interao com cada dispositivo por meio de drivers e criar modelos abstratos que permitam agrupar vrios dispositivos distintos sob a mesma interface de acesso. Gerncia de arquivos : esta funcionalidade construda sobre a gerncia de dispositivos e visa criar arquivos e diretrios, denindo sua interface de acesso e as regras para seu uso. importante observar que os conceitos abstratos de arquivo e diretrio so to importantes e difundidos que muitos sistemas operacionais os usam para permitir o acesso a recursos que nada tem a ver com armazenamento. Exemplos disso so as conexes de rede (nos sistemas UNIX e Windows, cada socket TCP visto como um descritor de arquivo no qual pode-se ler ou escrever dados) e as informaes do ncleo do sistema (como o diretrio /proc do UNIX).
Distribuir de forma justa, mas no necessariamente igual, pois as aplicaes tm demandas de processamento distintas; por exemplo, um navegador de Internet demanda menos o processador que um aplicativo de edio de vdeo, e por isso o navegador pode receber menos tempo de processador.
1

c Carlos Maziero

: Funcionalidades

No sistema operacional experimental Plan 9 [Pike et al., 1993], todos os recursos do sistema operacional so vistos como arquivos. Gerncia de proteo : com computadores conectados em rede e compartilhados por vrios usurios, importante denir claramente os recursos que cada usurio pode acessar, as formas de acesso permitidas (leitura, escrita, etc.) e garantir que essas denies sejam cumpridas. Para proteger os recursos do sistema contra acessos indevidos, necessrio: a) denir usurios e grupos de usurios; b) identicar os usurios que se conectam ao sistema, atravs de procedimentos de autenticao; c) denir e aplicar regras de controle de acesso aos recursos, relacionando todos os usurios, recursos e formas de acesso e aplicando essas regras atravs de procedimentos de autorizao; e nalmente d) registrar o uso dos recursos pelos usurios, para ns de auditoria e contabilizao. Alm dessas funcionalidades bsicas oferecidas pela maioria dos sistemas operacionais, vrias outras vm se agregar aos sistemas modernos, para cobrir aspectos complementares, como a interface grca, suporte de rede, uxos multimdia, gerncia de energia, etc. As funcionalidades do sistema operacional geralmente so inter-dependentes: por exemplo, a gerncia do processador depende de aspectos da gerncia de memria, assim como a gerncia de memria depende da gerncia de dispositivos e da gerncia de proteo. Alguns autores [Silberschatz et al., 2001, Tanenbaum, 2003] representam a estrutura do sistema operacional conforme indicado na Figura 2. Nela, o ncleo central implementa o acesso de baixo nvel ao hardware, enquanto os mdulos externos representam as vrias funcionalidades do sistema.

gerncia do processador suporte de rede

gerncia de memria gerncia de dispositivos

ncleo gerncia de proteo interface grca etc gerncia de arquivos

Figura 2: Funcionalidades do sistema operacional Uma regra importante a ser observada na construo de um sistema operacional a separao entre os conceitos de poltica e mecanismo2 . Como poltica consideram-se os aspectos de deciso mais abstratos, que podem ser resolvidos por algoritmos de nvel
Na verdade essa regra to importante que deveria ser levada em conta na construo de qualquer sistema computacional complexo.
2

c Carlos Maziero

: Estrutura de um sistema operacional

mais alto, como por exemplo decidir a quantidade de memria que cada aplicao ativa deve receber, ou qual o prximo pacote de rede a enviar para satisfazer determinadas especicaes de qualidade de servio. Por outro lado, como mecanismo consideram-se os procedimentos de baixo nvel usados para implementar as polticas, ou seja, atribuir ou retirar memria de uma aplicao, enviar ou receber um pacote de rede, etc. Os mecanismos devem ser sucientemente genricos para suportar mudanas de poltica sem necessidade de modicaes. Essa separao entre os conceitos de poltica e mecanismo traz uma grande exibilidade aos sistemas operacionais, permitindo alterar sua personalidade (sistemas mais interativos ou mais ecientes) sem ter de alterar o cdigo que interage diretamente com o hardware. Alguns sistemas, como o InfoKernel [Arpaci-Dusseau et al., 2003], permitem que as aplicaes escolham as polticas do sistema mais adequadas s suas necessidades.

Estrutura de um sistema operacional

Um sistema operacional no um bloco nico e fechado de software executando sobre o hardware. Na verdade, ele composto de diversos componentes com objetivos e funcionalidades complementares. Alguns dos componentes mais relevantes de um sistema operacional tpico so: Ncleo : o corao do sistema operacional, responsvel pela gerncia dos recursos do hardware usados pelas aplicaes. Ele tambm implementa as principais abstraes utilizadas pelos programas aplicativos. Drivers : mdulos de cdigo especcos para acessar os dispositivos fsicos. Existe um driver para cada tipo de dispositivo, como discos rgidos IDE, SCSI, portas USB, placas de vdeo, etc. Muitas vezes o driver construdo pelo prprio fabricante do hardware e fornecido em forma compilada (em linguagem de mquina) para ser acoplado ao restante do sistema operacional. Cdigo de inicializao : a inicializao do hardware requer uma srie de tarefas complexas, como reconhecer os dispositivos instalados, test-los e congur-los adequadamente para seu uso posterior. Outra tarefa importante carregar o ncleo do sistema operacional em memria e iniciar sua execuo. Programas utilitrios : so programas que facilitam o uso do sistema computacional, fornecendo funcionalidades complementares ao ncleo, como formatao de discos e mdias, congurao de dispositivos, manipulao de arquivos (mover, copiar, apagar), interpretador de comandos, terminal, interface grca, gerncia de janelas, etc. As diversas partes do sistema operacional esto relacionadas entre si conforme apresentado na Figura 3. A forma como esses diversos componentes so interligados e se relacionam varia de sistema para sistema; algumas possibilidades so discutidas na Seo 6. 10

c Carlos Maziero

: Conceitos de hardware

aplicativos

programas utilitrios

nvel de usurio

nvel de sistema ncleo software

cdigo de inicializao

drivers de dispositivos

controladoras de dispositivos hardware dispositivos fsicos

Figura 3: Estrutura de um sistema operacional

Conceitos de hardware

O sistema operacional interage diretamente com o hardware para fornecer servios s aplicaes. Para a compreenso dos conceitos implementados pelos sistemas operacionais, necessrio ter uma viso clara dos recursos fornecidos pelo hardware e a forma de acess-los. Esta seo apresenta uma reviso dos principais aspectos do hardware de um computador pessoal convencional. Um sistema de computao tpico constitudo de um ou mais processadores, responsveis pela execuo das instrues das aplicaes, uma rea de memria que armazena as aplicaes em execuo (seus cdigos e dados) e dispositivos perifricos que permitem o armazenamento de dados e a comunicao com o mundo exterior, como discos rgidos, terminais e teclados. A maioria dos computadores mono-processados atuais segue uma arquitetura bsica denida nos anos 40 por Jnos (John) Von Neumann, conhecida por arquitetura Von Neumann. A principal caracterstica desse modelo a ideia de programa armazenado, ou seja, o programa a ser executado reside na memria junto com os dados. Os principais elementos constituintes do computador esto interligados por um ou mais barramentos (para a transferncia de dados, endereos e sinais de controle). A Figura 4 ilustra a arquitetura de um computador tpico. O ncleo do sistema de computao o processador. Ele responsvel por continuamente ler instrues e dados da memria ou de perifricos, process-los e enviar os resultados de volta memria ou a outros perifricos. Um processador convencional normalmente constitudo de uma unidade lgica e aritmtica (ULA), que realiza os clculos e operaes lgicas, um conjunto de registradores para armazenar dados de trabalho e alguns registradores para funes especiais (contador de programa, ponteiro de pilha, ags de status, etc.).

11

c Carlos Maziero

: Interrupes

Memria

mouse

teclado

monitor

unidade de disco

conexo de rede

processador

MMU

controladora USB

control. de vdeo

control. de disco

control. de rede

dados endereos

controle

Figura 4: Arquitetura de um computador tpico Todas as transferncia de dados entre processador, memria e perifricos so feitas atravs dos barramentos: o barramento de endereos indica a posio de memria (ou o dispositivo) a acessar, o barramento de controle indica a operao a efetuar (leitura ou escrita) e o barramento de dados transporta a informao indicada entre o processador e a memria ou um controlador de dispositivo. O acesso memria geralmente mediado por um controlador especco (que pode estar sicamente dentro do prprio processador): a Unidade de Gerncia de Memria (MMU - Memory Management Unit). Ela responsvel por analisar cada endereo solicitado pelo processador, valid-los, efetuar as converses de endereamento necessrias e executar a operao solicitada pelo processador (leitura ou escrita de uma posio de memria). Os perifricos do computador (discos, teclado, monitor, etc.) so acessados atravs de circuitos especcos genericamente denominados controladores: a placa de vdeo permite o acesso ao monitor, a placa ethernet d acesso rede, o controlador USB permite acesso ao mouse, teclado e outros dispositivos USB externos. Para o processador, cada dispositivo representado por seu respectivo controlador. Os controladores podem ser acessados atravs de portas de entrada/sada endereveis: a cada controlador atribuda uma faixa de endereos de portas de entrada/sada. A Tabela 1 a seguir apresenta alguns endereos portas de entrada/sada para acessar controladores em um PC tpico:

5.1

Interrupes

Quando um controlador de perifrico tem uma informao importante a fornecer ao processador, ele tem duas alternativas de comunicao: Aguardar at que o processador o consulte, o que poder ser demorado caso o processador esteja ocupado com outras tarefas (o que geralmente ocorre);

12

c Carlos Maziero

: Interrupes

dispositivo endereos de acesso teclado 0060h-006Fh barramento IDE primrio 0170h-0177h barramento IDE secundrio 01F0h-01F7Fh porta serial COM1 02F8h-02FFh porta serial COM2 03F8h-03FFh Tabela 1: Endereos de acesso a dispositivos Noticar o processador atravs do barramento de controle, enviando a ele uma requisio de interrupo (IRQ Interrupt ReQuest). Ao receber a requisio de interrupo, os circuitos do processador suspendem seu uxo de execuo corrente e desviam para um endereo pr-denido, onde se encontra uma rotina de tratamento de interrupo (interrupt handler). Essa rotina responsvel por tratar a interrupo, ou seja, executar as aes necessrias para atender o dispositivo que a gerou. Ao nal da rotina de tratamento da interrupo, o processador retoma o cdigo que estava executando quando recebeu a requisio. A Figura 5 representa os principais passos associados ao tratamento de uma interrupo envolvendo a placa de rede Ethernet, enumerados a seguir:
Memria 1 4 5 6 rede 2 processador MMU controladora de rede
rotina de tratamento de interrupo

programa em execuo

dados

endereos

controle

Figura 5: Roteiro tpico de um tratamento de interrupo 1. O processador est executando um programa qualquer (em outras palavras, um uxo de execuo); 13

c Carlos Maziero

: Interrupes

2. Um pacote vindo da rede recebido pela placa Ethernet; 3. A placa envia uma solicitao de interrupo (IRQ) ao processador; 4. O processamento desviado do programa em execuo para a rotina de tratamento da interrupo; 5. A rotina de tratamento executada para receber as informaes da placa de rede (via barramentos de dados e de endereos) e atualizar as estruturas de dados do sistema operacional; 6. A rotina de tratamento da interrupo nalizada e o processador retorna execuo do programa que havia sido interrompido. Esse roteiro de aes ocorre a cada requisio de interrupo recebida pelo processador. Cada interrupo geralmente corresponde a um evento ocorrido em um dispositivo perifrico: a chegada de um pacote de rede, um click no mouse, uma operao concluda pelo controlador de disco, etc. Isso representa centenas ou mesmo milhares de interrupes recebidas por segundo, dependendo da carga e da congurao do sistema (nmero e natureza dos perifricos). Por isso, as rotinas de tratamento de interrupo devem ser curtas e realizar suas tarefas rapidamente (para no prejudicar o desempenho do sistema). Normalmente o processador recebe e trata cada interrupo recebida, mas nem sempre isso possvel. Por exemplo, receber e tratar uma interrupo pode ser problemtico caso o processador j esteja tratando outra interrupo. Por essa razo, o processador pode decidir ignorar temporariamente algumas interrupes, se necessrio. Isso feito ajustando o bit correspondente interrupo em um registrador especco do processador. Para distinguir interrupes geradas por dispositivos distintos, cada interrupo identicada por um inteiro, normalmente com 8 bits. Como cada interrupo pode exigir um tipo de tratamento diferente (pois os dispositivos so diferentes), cada IRQ deve disparar sua prpria rotina de tratamento de interrupo. A maioria das arquiteturas atuais dene um vetor de endereos de funes denominado Vetor de Interrupes (IV - Interrupt Vector); cada entrada desse vetor aponta para a rotina de tratamento da interrupo correspondente. Por exemplo, se a entrada 5 do vetor contm o valor 3C20h, ento a rotina de tratamento da IRQ 5 iniciar na posio 3C20h da memria RAM. O vetor de interrupes reside em uma posio xa da memria RAM, denida pelo fabricante do processador, ou tem sua posio indicada pelo contedo de um registrador da CPU especco para esse m. As interrupes recebidas pelo processador tm como origem eventos externos a ele, ocorridos nos dispositivos perifricos e reportados por seus controladores. Entretanto, alguns eventos gerados pelo prprio processador podem ocasionar o desvio da execuo usando o mesmo mecanismo das interrupes: so as excees. Eventos como instrues ilegais (inexistentes ou com operandos invlidos), tentativa de diviso por zero ou outros erros de software disparam excees no processador, que resultam na ativao de uma rotina de tratamento de exceo, usando o mesmo mecanismo das interrupes (e

14

c Carlos Maziero

: Proteo do ncleo

Tabela 2: Vetor de Interrupes do processador Pentium [Patterson and Henessy, 2005] IRQ 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19-31 32-255 Descrio divide error debug exception null interrupt breakpoint INTO-detected overow bound range exception invalid opcode device not available double fault coprocessor segment overrun invalid task state segment segment not present stack fault general protection page fault Intel reserved oating point error alignment check machine check Intel reserved maskable interrupts (devices & exceptions)

o mesmo vetor de endereos de funes). A Tabela 2 representa o vetor de interrupes do processador Intel Pentium (extrada de [Patterson and Henessy, 2005]). O mecanismo de interrupo torna eciente a interao do processador com os dispositivos perifricos. Se no existissem interrupes, o processador perderia muito tempo varrendo todos os dispositivos do sistema para vericar se h eventos a serem tratados. Alm disso, as interrupes permitem construir funes de entrada/sada assncronas, ou seja, o processador no precisa esperar a concluso de cada operao solicitada a um dispositivo, pois o dispositivo gera uma interrupo para avisar o processador quando a operao for concluda. Interrupes no so raras, pelo contrrio: em um computador pessoal, o processador trata de centenas a milhares de interrupes por segundo, dependendo da carga do sistema e dos perifricos instalados.

5.2

Proteo do ncleo

Um sistema operacional deve gerenciar os recursos do hardware, fornecendo-os s aplicaes conforme suas necessidades. Para assegurar a integridade dessa gerncia, essencial garantir que as aplicaes no consigam acessar o hardware diretamente, mas sempre atravs de pedidos ao sistema operacional, que avalia e intermedeia todos 15

c Carlos Maziero

: Proteo do ncleo

os acessos ao hardware. Mas como impedir as aplicaes de acessar o hardware diretamente? Ncleo, drivers, utilitrios e aplicaes so constitudos basicamente de cdigo de mquina. Todavia, devem ser diferenciados em sua capacidade de interagir com o hardware: enquanto o ncleo e os drivers devem ter pleno acesso ao hardware, para poder congur-lo e gerenci-lo, os utilitrios e os aplicativos devem ter acesso mais restrito a ele, para no interferir nas conguraes e na gerncia, o que acabaria desestabilizando o sistema inteiro. Alm disso, aplicaes com acesso pleno ao hardware tornariam inteis os mecanismos de segurana e controle de acesso aos recursos (tais como arquivos, diretrios e reas de memria). Para permitir diferenciar os privilgios de execuo dos diferentes tipos de software, os processadores modernos contam com dois ou mais nveis de privilgio de execuo. Esses nveis so controlados por ags especiais nos processadores, e as formas de mudana de um nvel de execuo para outro so controladas estritamente pelo processador. O processador Pentium, por exemplo, conta com 4 nveis de privilgio (sendo 0 o nvel mais privilegiado), embora a maioria dos sistemas operacionais construdos para esse processador s use os nveis extremos (0 para o ncleo e drivers do sistema operacional e 3 para utilitrios e aplicaes). Na forma mais simples desse esquema, podemos considerar dois nveis bsicos de privilgio: Nvel ncleo : tambm denominado nvel supervisor, sistema, monitor ou ainda kernel space. Para um cdigo executando nesse nvel, todo o processador est acessvel: todos os recursos internos do processador (registradores e portas de entrada/sada) e reas de memria podem ser acessados. Alm disso, todas as instrues do processador podem ser executadas. Ao ser ligado, o processador entra em operao neste nvel. Nvel usurio (ou userspace): neste nvel, somente um sub-conjunto das instrues do processador, registradores e portas de entrada/sada esto disponveis. Instrues perigosas como HALT (parar o processador) e RESET (reiniciar o processador) so proibidas para todo cdigo executando neste nvel. Alm disso, o hardware restringe o uso da memria, permitindo o acesso somente a reas previamente denidas. Caso o cdigo em execuo tente executar uma instruo proibida ou acessar uma rea de memria inacessvel, o hardware ir gerar uma exceo, desviando a execuo para uma rotina de tratamento dentro do ncleo, que provavelmente ir abortar o programa em execuo (e tambm gerar a famosa frase este programa executou uma instruo ilegal e ser nalizado, no caso do Windows). fcil perceber que, em um sistema operacional convencional, o ncleo e os drivers operam no nvel ncleo, enquanto os utilitrios e as aplicaes operam no nvel usurio, connados em reas de memria distintas, conforme ilustrado na Figura 6. Todavia, essa separao nem sempre segue uma regra to simples; outras opes de organizao de sistemas operacionais sero abordadas na Seo 6.

16

c Carlos Maziero

: Chamadas de sistema

nvel usurio

aplicao

aplicao

aplicao

aplicao

nvel ncleo

ncleo

hardware

Figura 6: Separao entre o ncleo e as aplicaes

5.3

Chamadas de sistema

O connamento de cada aplicao em sua rea de memria, imposto pelos mapeamentos de memria realizados pela MMU nos acessos em nvel usurio, prov robustez e conabilidade ao sistema, pois garante que uma aplicao no poder interferir nas reas de memria de outras aplicaes ou do ncleo. Entretanto, essa proteo introduz um novo problema: como chamar, a partir de uma aplicao, as rotinas oferecidas pelo ncleo para o acesso ao hardware e suas abstraes? Em outras palavras, como uma aplicao pode acessar a placa de rede para enviar/receber dados, se no tem privilgio para acessar as portas de entrada/sada correspondentes nem pode invocar o cdigo do ncleo que implementa esse acesso (pois esse cdigo reside em outra rea de memria)? A resposta a esse problema est no mecanismo de interrupo, apresentado na Seo 5.1. Os processadores implementam uma instruo especial que permite acionar o mecanismo de interrupo de forma intencional, sem depender de eventos externos ou internos. Ao ser executada, essa instruo (int no Pentium, syscall no MIPS) comuta o processador para o nvel privilegiado e procede de forma similar ao tratamento de uma interrupo. Por essa razo, esse mecanismo denominado interrupo de software, ou trap. Processadores modernos oferecem instrues especcas para entrar/sair do modo privilegiado, como SYSCALL e SYSRET (nos processadores Pentium 64 bits) e tambm um conjunto de registradores especcos para essa operao, o que permite a transferncia rpida do controle para o ncleo, com custo menor que o tratamento de uma interrupo. A ativao de procedimentos do ncleo usando interrupes de software (ou outros mecanismos correlatos) denominada chamada de sistema (system call ou syscall). Os sistemas operacionais denem chamadas de sistema para todas as operaes envolvendo o acesso a recursos de baixo nvel (perifricos, arquivos, alocao de memria, etc.) ou abstraes lgicas (criao e nalizao de tarefas, operadores de sincronizao e comunicao, etc.). Geralmente as chamadas de sistema so oferecidas para as aplicaes em modo usurio atravs de uma biblioteca do sistema (system library), que prepara os parmetros, invoca a interrupo de software e retorna aplicao os resultados obtidos.

17

c Carlos Maziero

: Chamadas de sistema

A Figura 7 ilustra o funcionamento bsico de uma chamada de sistema (a chamada read, que l dados de um arquivo previamente aberto). Os seguintes passos so realizados: 1. No nvel usurio, a aplicao invoca a funo read(fd, &buffer, bytes) da biblioteca de sistema (no Linux a biblioteca GNU C Library, ou glibc; no Windows, essas funes so implementadas pela API Win32). 2. A funo read preenche uma rea de memria com os parmetros recebidos e escreve o endereo dessa rea em um registrador da CPU. Em outro registrador, ela escreve o cdigo da chamada de sistema desejada (no caso do Linux, seria 03h para a syscall read). 3. A funo read invoca uma interrupo de software (no caso do Linux, sempre invocada a interrupo 80h). 4. O processador comuta para o nvel privilegiado (kernel level) e transfere o controle para a rotina apontada pela entrada 80h do vetor de interrupes. 5. A rotina obtm o endereo dos parmetros, verica a validade de cada um deles e realiza (ou agenda para execuo posterior) a operao desejada pela aplicao. 6. Ao nal da execuo da rotina, eventuais valores de retorno so escritos na rea de memria da aplicao e o processamento retorna funo read, em modo usurio. 7. A funo read naliza sua execuo e retorna o controle aplicao. 8. Caso a operao solicitada no possa ser realizada imediatamente, a rotina de tratamento da interrupo de software passa o controle para a gerncia de atividades, ao invs de retornar diretamente da interrupo de software para a aplicao solicitante. Isto ocorre, por exemplo, quando solicitada a leitura de uma entrada do teclado. 9. Na sequncia, a gerncia de atividades devolve o controle do processador a outra aplicao que tambm esteja aguardando o retorno de uma interrupo de software, e cuja operao solicitada j tenha sido concluda. A maioria dos sistemas operacionais implementa centenas de chamadas de sistema distintas, para as mais diversas nalidades. O conjunto de chamadas de sistema oferecidas por um ncleo dene a API (Application Programming Interface) desse sistema operacional. Exemplos de APIs bem conhecidas so a Win32, oferecida pelos sistemas Microsoft derivados do Windows NT, e a API POSIX [Gallmeister, 1994], que dene um padro de interface de ncleo para sistemas UNIX.

18

c Carlos Maziero

: Arquiteturas de Sistemas Operacionais

aplicao

read(...) 2

1
int

nvel usurio nvel ncleo

4 6

chamada 5 de sistema

gerncia de atividades

vetor de interrupes
79h 80h 81h 82h

Figura 7: Roteiro tpico de uma chamada de sistema

Arquiteturas de Sistemas Operacionais

Embora a denio de nveis de privilgio (Seo 5.3) imponha uma estruturao mnima a um sistema operacional, as vrias partes que compem o sistema podem ser organizadas de diversas formas, separando suas funcionalidades e modularizando seu projeto. Nesta seo sero apresentadas as arquiteturas mais populares para a organizao de sistemas operacionais.

6.1

Sistemas monolticos

Em um sistema monoltico, todos os componentes do ncleo operam em modo ncleo e se inter-relacionam conforme suas necessidades, sem restries de acesso entre si, pois o cdigo no nvel ncleo tem acesso pleno a todos os recursos e reas de memria. A Figura 8 ilustra essa arquitetura. A grande vantagem dessa arquitetura seu desempenho: qualquer componente do ncleo pode acessar os demais componentes, toda a memria ou mesmo dispositivos perifricos diretamente, pois no h barreiras impedindo esse acesso. A interao direta entre componentes tambm leva a sistemas mais compactos. Todavia, a arquitetura monoltica pode pagar um preo elevado por seu desempenho: a robustez e a facilidade de desenvolvimento. Caso um componente do ncleo perca o controle devido a algum erro, esse problema pode se alastrar rapidamente por todo o ncleo, levando o sistema ao colapso (travamento, reinicializao ou funcionamento errtico). Alm disso, a manuteno e evoluo do ncleo se tornam mais complexas, porque as dependncias e pontos de interao entre os componentes podem no ser evidentes: pequenas alteraes na estrutura de dados de um componente podem ter

19

c Carlos Maziero

: Sistemas em camadas

nvel usurio

aplicao

aplicao

aplicao

aplicao

memory operations

le operations

process manager

CPU scheduler

network operations

memory manager

nvel ncleo
NTFS le system

access control kernel data structures

network protocols

block I/O operations

VFAT le system

MMU control

USB driver

SATA driver

Bluetooth driver

network driver

hardware

Figura 8: Uma arquitetura monoltica um impacto inesperado em outros componentes, caso estes acessem aquela estrutura diretamente. A arquitetura monoltica foi a primeira forma de organizar os sistemas operacionais; sistemas UNIX antigos e o MS-DOS seguiam esse modelo. Atualmente, apenas sistemas operacionais embarcados so totalmente monolticos, devido s limitaes do hardware sobre o qual executam. O ncleo do Linux nasceu monoltico, mas vem sendo paulatinamente estruturado e modularizado desde a verso 2.0 (embora boa parte de seu cdigo ainda permanea no nvel de ncleo).

6.2

Sistemas em camadas

Uma forma mais elegante de estruturar um sistema operacional faz uso da noo de camadas: a camada mais baixa realiza a interface com o hardware, enquanto as camadas intermedirias provem nveis de abstrao e gerncia cada vez mais sosticados. Por m, a camada superior dene a interface do ncleo para as aplicaes (as chamadas de sistema). Essa abordagem de estruturao de software fez muito sucesso no domnio das redes de computadores, atravs do modelo de referncia OSI (Open Systems Interconnection) [Day, 1983], e tambm seria de se esperar sua adoo no domnio dos sistemas operacionais. No entanto, alguns inconvenientes limitam sua aceitao nesse contexto:

20

c Carlos Maziero

: Sistemas micro-ncleo

O empilhamento de vrias camadas de software faz com que cada pedido de uma aplicao demore mais tempo para chegar at o dispositivo perifrico ou recurso a ser acessado, prejudicando o desempenho do sistema. No bvio como dividir as funcionalidades de um ncleo de sistema operacional em camadas horizontais de abstrao crescente, pois essas funcionalidades so inter-dependentes, embora tratem muitas vezes de recursos distintos. Em decorrncia desses inconvenientes, a estruturao em camadas apenas parcialmente adotada hoje em dia. Muitos sistemas implementam uma camada inferior de abstrao do hardware para interagir com os dispositivos (a camada HAL Hardware Abstraction Layer, implementada no Windows NT e seus sucessores), e tambm organizam em camadas alguns sub-sistemas como a gerncia de arquivos e o suporte de rede (seguindo o modelo OSI). Como exemplos de sistemas fortemente estruturados em camadas podem ser citados o IBM OS/2 e o MULTICS [Corbat and Vyssotsky, 1965].

6.3

Sistemas micro-ncleo

Uma outra possibilidade de estruturao consiste em retirar do ncleo todo o cdigo de alto nvel (normalmente associado s polticas de gerncia de recursos), deixando no ncleo somente o cdigo de baixo nvel necessrio para interagir com o hardware e criar as abstraes fundamentais (como a noo de atividade). Por exemplo, usando essa abordagem o cdigo de acesso aos blocos de um disco rgido seria mantido no ncleo, enquanto as abstraes de arquivo e diretrio seriam criadas e mantidas por um cdigo fora do ncleo, executando da mesma forma que uma aplicao do usurio. Por fazer os ncleos de sistema carem menores, essa abordagem foi denominada micro-ncleo (ou -kernel). Um micro-ncleo normalmente implementa somente a noo de atividade, de espaos de memria protegidos e de comunicao entre atividades. Todos os aspectos de alto nvel, como polticas de uso do processador e da memria, o sistema de arquivos e o controle de acesso aos recursos so implementados fora do ncleo, em processos que se comunicam usando as primitivas do ncleo. A Figura 9 ilustra essa abordagem. Em um sistema micro-ncleo, as interaes entre componentes e aplicaes so feitas atravs de trocas de mensagens. Assim, se uma aplicao deseja abrir um arquivo no disco rgido, envia uma mensagem para o gerente de arquivos que, por sua vez, se comunica com o gerente de dispositivos para obter os blocos de dados relativos ao arquivo desejado. Os processos no podem se comunicar diretamente, devido s restries impostas pelos mecanismos de proteo do hardware. Por isso, todas as mensagens so transmitidas atravs de servios do micro-ncleo, como mostra a Figura 9. Como os processos tm de solicitar servios uns dos outros, para poder realizar suas tarefas, essa abordagem tambm foi denominada cliente-servidor. O micro-ncleos foram muito investigados durante os anos 80. Dois exemplos clssicos dessa abordagem so os sistemas Mach [Rashid et al., 1989] e Chorus [Rozier et al., 1992]. As principais vantagens dos sistemas micro-ncleo so sua robustez e exibilidade: caso um sub-sistema tenha problemas, os mecanismos de proteo de memria e nveis de privilgio iro conn-lo, impedindo que a instabilidade se 21

c Carlos Maziero

: Mquinas virtuais

user application
aplicaes sistema operacional

user application

user application

process manager memory manager

le system

protection manager

block IO operations network driver

network protocols

MMU control

disk driver

nvel usurio nvel ncleo

micro-kernel hardware

Figura 9: Viso geral de uma arquitetura micro-ncleo alastre ao restante do sistema. Alm disso, possvel customizar o sistema operacional, iniciando somente os componentes necessrios ou escolhendo os componentes mais adequados s aplicaes que sero executadas. Vrios sistemas operacionais atuais adotam parcialmente essa estruturao; por exemplo, o MacOS X da Apple tem suas razes no sistema Mach, ocorrendo o mesmo com o Digital UNIX. Todavia, o custo associado s trocas de mensagens entre componentes pode ser bastante elevado, o que prejudica seu desempenho e diminui a aceitao desta abordagem. O QNX um dos poucos exemplos de micro-ncleo amplamente utilizado, sobretudo em sistemas embarcados e de tempo-real.

6.4

Mquinas virtuais

Para que programas e bibliotecas possam executar sobre uma determinada plataforma computacional, necessrio que tenham sido compilados para ela, respeitando o conjunto de instrues do processador e o conjunto de chamadas do sistema operacional. Da mesma forma, um sistema operacional s poder executar sobre uma plataforma de hardware se for compatvel com ela. Nos sistemas atuais, as interfaces de baixo nvel so pouco exveis: geralmente no possvel criar novas instrues de processador ou novas chamadas de sistema, ou mudar sua semntica. Por isso, um sistema operacional s funciona sobre o hardware para o qual foi construdo, uma biblioteca s funciona sobre o hardware e sistema operacional para os quais foi projetada e as aplicaes tambm tm de obedecer a interfaces pr-denidas. Todavia, possvel contornar os problemas de compatibilidade entre os componentes de um sistema atravs de tcnicas de virtualizao. Usando os servios oferecidos por um determinado componente do sistema, possvel construir uma camada de software que 22

c Carlos Maziero

: Mquinas virtuais

oferea aos demais componentes servios com outra interface. Essa camada permitir assim o acoplamento entre interfaces distintas, de forma que um programa desenvolvido para uma plataforma A possa executar sobre uma plataforma distinta B. O sistema computacional visto atravs dessa camada denominado mquina virtual. A Figura 10, extrada de [Smith and Nair, 2004], mostra um exemplo de mquina virtual, onde uma camada de virtualizao permite executar um sistema operacional Windows e suas aplicaes sobre uma plataforma de hardware Sparc, distinta daquela para a qual foi projetado (Intel/AMD).
sistema convidado
Aplics Windows Windows
camada de virtualizao

Aplics Windows Windows

monitor sistema hospedeiro

Sparc

x86

Mquina Virtual

Figura 10: Uma mquina virtual [Smith and Nair, 2004]. Um ambiente de mquina virtual consiste de trs partes bsicas, que podem ser observadas na Figura 10: O sistema real, ou sistema hospedeiro (host system), que contm os recursos reais de hardware e software do sistema; o sistema virtual, tambm denominado sistema convidado (guest system), que executa sobre o sistema virtualizado; em alguns casos, vrios sistemas virtuais podem coexistir, executando sobre o mesmo sistema real; a camada de virtualizao, denominada hipervisor ou monitor de virtualizao (VMM - Virtual Machine Monitor), que constri as interfaces virtuais a partir da interface real. Na dcada de 1970, os pesquisadores Popek & Goldberg formalizaram vrios conceitos associados s mquinas virtuais, e deniram as condies necessrias para que uma plataforma de hardware suporte de forma eciente a virtualizao [Popek and Goldberg, 1974]. Nessa mesma poca surgem as primeiras experincias concretas de utilizao de mquinas virtuais para a execuo de aplicaes, com o ambiente UCSD p-System, no qual programas Pascal so compilados para execuo sobre um hardware abstrato denominado P-Machine. Com o aumento de desempenho e funcionalidades do hardware PC e o surgimento da linguagem Java, no incio dos anos 90, o interesse pelas tecnologias de virtualizao voltou tona. Atualmente, as solues de virtualizao de linguagens e de plataformas vm despertando grande interesse do mercado. Vrias linguagens so compiladas para mquinas virtuais portveis e os processadores mais recentes trazem um suporte nativo virtualizao de hardware, nalmente respeitando as condies conceituais denidas no incio dos anos 70. 23

c Carlos Maziero

: Mquinas virtuais

Existem diversas possibilidades de implementao de sistemas de mquinas virtuais. De acordo com o tipo de sistema convidado suportado, os ambientes de mquinas virtuais podem ser divididos em duas grandes famlias (Figura 11): Mquinas virtuais de aplicao : so ambientes de mquinas virtuais destinados a suportar apenas um processo ou aplicao convidada especca. A mquina virtual Java um exemplo desse tipo de ambiente. Mquinas virtuais de sistema : so construdos para suportar sistemas operacionais convidados completos, com aplicaes convidadas executando sobre eles. Como exemplos podem ser citados os ambientes VMWare, Xen e VirtualBox.

Espao de usurio Aplics Linux Aplic Java JVM ncleo Linux ncleo Linux hardware x86 VM de aplicao ncleo Windows hipervisor hardware x86 VM de sistema Aplics Linux Aplics Windows

Figura 11: Mquinas virtuais de aplicao e de sistema. As mquinas virtuais de aplicao so geralmente usadas como suporte de execuo de linguagens de programao. As primeiras experincias com linguagens usando mquinas virtuais remontam aos anos 1970, com a linguagem UCSD Pascal (da Universidade da Califrnia em San Diego). Na poca, um programa escrito em Pascal era compilado em um cdigo binrio denominado P-Code, que executava sobre o processador abstrato P-Machine. O interpretador de P-Codes era bastante compacto e facilmente portvel, o que tornou o sistema P muito popular. Hoje, muitas linguagens adotam estratgias similares, como Java, C#, Python, Perl, Lua e Ruby. Em C#, o cdigo-fonte compilado em um formato intermedirio denominado CIL (Common Intermediate Language), que executa sobre uma mquina virtual CLR (Common Language Runtime). CIL e CLR fazem parte da infraestrutura .NET da Microsoft. Mquinas virtuais de sistema suportam um ou mais sistemas operacionais convidados, com suas respectivas aplicaes, que executam de forma isolada e independente. Em uma mquina virtual, cada sistema operacional convidado tem a iluso de executar sozinho sobre uma plataforma de hardware exclusiva. Como o sistema operacional convidado e o ambiente de execuo dentro da mquina virtual so idnticos ao da mquina real, possvel usar os softwares j construdos para a mquina real dentro das mquinas virtuais. Essa transparncia evita ter de construir novas aplicaes ou adaptar as j existentes. 24

c Carlos Maziero

: Mquinas virtuais

As mquinas virtuais de sistema constituem a primeira abordagem usada para a construo de hipervisores, desenvolvida na dcada de 1960. No que diz respeito sua arquitetura, existem basicamente dois tipos de hipervisores de sistema, apresentados na Figura 12: Hipervisores nativos (ou de tipo I): o hipervisor executa diretamente sobre o hardware da mquina real, sem um sistema operacional subjacente. A funo do hipervisor multiplexar os recursos de hardware (memria, discos, interfaces de rede, etc.) de forma que cada mquina virtual veja um conjunto de recursos prprio e independente. Alguns exemplos de sistemas que empregam esta abordagem so o IBM OS/370, o VMWare ESX Server e o ambiente Xen. Hipervisores convidados (ou de tipo II): o hipervisor executa como um processo normal sobre um sistema operacional hospedeiro. O hipervisor usa os recursos oferecidos pelo sistema operacional real para oferecer recursos virtuais ao sistema operacional convidado que executa sobre ele. Exemplos de sistemas que adotam esta estrutura incluem o VMWare Workstation, o QEmu e o VirtualBox.
aplics

aplics

aplics

aplics

OS 1

OS 2 hipervisor hardware host OS

guest OS hipervisor

hardware hipervisor convidado

hipervisor nativo

Figura 12: Arquiteturas de mquinas virtuais de sistema. Os trabalhos [Goldberg, 1973, Blunden, 2002] relacionam algumas vantagens para a utilizao de mquinas virtuais em sistemas de computao: Aperfeioamento e testes de novos sistemas operacionais; Ensino prtico de sistemas operacionais e programao de baixo nvel; Executar diferentes sistemas operacionais sobre o mesmo hardware, simultaneamente; Simular conguraes e situaes diferentes do mundo real, como por exemplo, mais memria disponvel, outros dispositivos de E/S;

25

c Carlos Maziero

: Um breve histrico dos sistemas operacionais

Simular alteraes e falhas no hardware para testes ou recongurao de um sistema operacional, provendo conabilidade e escalabilidade para as aplicaes; Garantir a portabilidade das aplicaes legadas (que executariam sobre uma VM simulando o sistema operacional original); Desenvolvimento de novas aplicaes para diversas plataformas, garantindo a portabilidade destas aplicaes; Diminuir custos com hardware. A principal desvantagem do uso de mquinas virtuais o custo adicional de execuo dos processos na mquina virtual em comparao com a mquina real. Esse custo muito varivel, podendo passar de 50% em plataformas sem suporte de hardware virtualizao, como os PCs de plataforma Intel mais antigos [Dike, 2000, Blunden, 2002]. Todavia, pesquisas recentes tm obtido a reduo desse custo a patamares abaixo de 20%, graas sobretudo a ajustes no cdigo do sistema hospedeiro [King et al., 2003]. Esse problema no existe em ambientes cujo hardware oferece suporte virtualizao, como o caso dos mainframes e dos processadores Intel/AMD mais recentes.

Um breve histrico dos sistemas operacionais

Os primeiros sistemas de computao, no nal dos anos 40 e incio dos anos 50, no possuam sistema operacional. Por outro lado, os sistemas de computao atuais possuem sistemas operacionais grandes, complexos e em constante evoluo. A seguir so apresentados alguns dos marcos mais relevantes na histria dos sistemas operacionais [Foundation, 2005]: Anos 40 : cada programa executava sozinho e tinha total controle do computador. A carga do programa em memria, a varredura dos perifricos de entrada para busca de dados, a computao propriamente dita e o envio dos resultados para os perifrico de sada, byte a byte, tudo devia ser programado detalhadamente pelo desenvolvedor da aplicao. Anos 50 : os sistemas de computao fornecem bibliotecas de sistema (system libraries) que encapsulam o acesso aos perifricos, para facilitar a programao de aplicaes. Algumas vezes um programa monitor (system monitor) auxilia a carga e descarga de aplicaes e/ou dados entre a memria e perifricos (geralmente leitoras de carto perfurado, tas magnticas e impressoras de caracteres). 1961 : o grupo do pesquisador Fernando Corbat, do MIT, anuncia o desenvolvimento do CTSS Compatible Time-Sharing System [Corbat et al., 1962], o primeiro sistema operacional com compartilhamento de tempo. 1965 : a IBM lana o OS/360, um sistema operacional avanado, com compartilhamento de tempo e excelente suporte a discos.

26

c Carlos Maziero

: Um breve histrico dos sistemas operacionais

1965 : um projeto conjunto entre MIT, GE e Bell Labs dene o sistema operacional Multics, cujas ideias inovadoras iro inuenciar novos sistemas durante dcadas. 1969 : Ken Thompson e Dennis Ritchie, pesquisadores dos Bell Labs, criam a primeira verso do UNIX. 1981 : a Microsoft lana o MS-DOS, um sistema operacional comprado da empresa Seattle Computer Products em 1980. 1984 : a Apple lana o sistema operacional Macintosh OS 1.0, o primeiro a ter uma interface grca totalmente incorporada ao sistema. 1985 : primeira tentativa da Microsoft no campo dos sistemas operacionais com interface grca, atravs do MS-Windows 1.0. 1987 : Andrew Tanenbaum, um professor de computao holands, desenvolve um sistema operacional didtico simplicado, mas respeitando a API do UNIX, que foi batizado como Minix. 1987 : IBM e Microsoft apresentam a primeira verso do OS/2, um sistema multitarefa destinado a substituir o MS-DOS e o Windows. Mais tarde, as duas empresas rompem a parceria; a IBM continua no OS/2 e a Microsoft investe no ambiente Windows. 1991 : Linus Torvalds, um estudante de graduao nlands, inicia o desenvolvimento do Linux, lanando na rede Usenet o ncleo 0.01, logo abraado por centenas de programadores ao redor do mundo. 1993 : a Microsoft lana o Windows NT, o primeiro sistema 32 bits da empresa. 1993 : lanamento dos UNIX de cdigo aberto FreeBSD e NetBSD. 2001 : a Apple lana o MacOS X, um sistema operacional derivado da famlia UNIX BSD. 2001 : lanamento do Windows XP. 2004 : lanamento do ncleo Linux 2.6. 2006 : lanamento do Windows Vista. Esse histrico reete apenas o surgimento de alguns sistemas operacionais relativamente populares; diversos sistemas acadmicos ou industriais de grande importncia pelas contribuies inovadoras, como Mach, Chorus, QNX e Plan 9, no esto representados.

27

c Carlos Maziero

: REFERNCIAS

Referncias
[Arpaci-Dusseau et al., 2003] Arpaci-Dusseau, A., Arpaci-Dusseau, R., Burnett, N., Denehy, T., Engle, T., Gunawi, H., Nugent, J., and Popovici, F. (2003). Transforming policies into mechanisms with InfoKernel. In 19th ACM Symposium on Operating Systems Principles. [Blunden, 2002] Blunden, B. (2002). Virtual Machine Design and Implementation in C/C++. Worldware Publishing. [Corbat et al., 1962] Corbat, F., Daggett, M., and Daley, R. (1962). An experimental time-sharing system. In Proceedings of the Spring Joint Computer Conference. [Corbat and Vyssotsky, 1965] Corbat, F. J. and Vyssotsky, V. A. (1965). Introduction and overview of the Multics system. In AFIPS Conference Proceedings, pages 185196. [Dasgupta et al., 1991] Dasgupta, P., Richard J. LeBlanc, J., Ahamad, M., and Ramachandran, U. (1991). The Clouds distributed operating system. Computer, 24(11):3444. [Day, 1983] Day, J. (1983). The OSI reference model. Proceedings of the IEEE. [Dike, 2000] Dike, J. (2000). A user-mode port of the Linux kernel. In Proceedings of the 4th Annual Linux Showcase & Conference. [Foundation, 2005] Foundation, http://www.wikipedia.org. W. (2005). Wikipedia online enciclopedia.

[Gallmeister, 1994] Gallmeister, B. (1994). POSIX.4: Programming for the Real World. OReilly Media, Inc. [Goldberg, 1973] Goldberg, R. (1973). Architecture of virtual machines. In AFIPS National Computer Conference. [King et al., 2003] King, S., Dunlap, G., and Chen, P. (2003). Operating system support for virtual machines. In Proceedings of the USENIX Technical Conference. [Patterson and Henessy, 2005] Patterson, D. and Henessy, J. (2005). Organizao e Projeto de Computadores. Campus. [Pike et al., 1993] Pike, R., Presotto, D., Thompson, K., Trickey, H., and Winterbottom, P. (1993). The use of name spaces in Plan 9. Operating Systems Review, 27(2):7276. [Popek and Goldberg, 1974] Popek, G. and Goldberg, R. (1974). Formal requirements for virtualizable third generation architectures. Communications of the ACM, 17(7):412 421. [Rashid et al., 1989] Rashid, R., Julin, D., Orr, D., Sanzi, R., Baron, R., Forin, A., Golub, D., and Jones, M. B. (1989). Mach: a system software kernel. In Proceedings of the 1989 IEEE International Conference, COMPCON, pages 176178, San Francisco, CA, USA. IEEE Comput. Soc. Press. 28

c Carlos Maziero

: REFERNCIAS

[Rozier et al., 1992] Rozier, M., Abrossimov, V., Armand, F., Boule, I., Gien, M., Guillemont, M., Herrman, F., Kaiser, C., Langlois, S., Lonard, P., and Neuhauser, W. (1992). Overview of the Chorus distributed operating system. In Workshop on Micro-Kernels and Other Kernel Architectures, pages 3970, Seattle WA (USA). [Silberschatz et al., 2001] Silberschatz, A., Galvin, P., and Gagne, G. (2001). Sistemas Operacionais Conceitos e Aplicaes. Campus. [Smith and Nair, 2004] Smith, J. and Nair, R. (2004). Virtual Machines: Architectures, Implementations and Applications. Morgan Kaufmann. [Tanenbaum, 2003] Tanenbaum, A. (2003). Sistemas Operacionais Modernos, 2a edio. Pearson Prentice-Hall. [Tanenbaum et al., 1991] Tanenbaum, A., Kaashoek, M., van Renesse, R., and Bal, H. (1991). The Amoeba distributed operating system a status report. Computer Communications, 14:324335.

29