Sistemas Operacionais I - Conceitos Bsicos

Prof. Carlos Alberto Maziero PPGIA CCET PUCPR http://www.ppgia.pucpr.br/maziero 16 de agosto de 2007

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 e 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.

1 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.
Copyright (c) 2007 Carlos Alberto Maziero. garantida a permisso para copiar, distribuir e/ou modicar este documento sob os termos da Licena de Documentao Livre GNU (GNU Free Documentation License), Verso 1.2 ou qualquer verso posterior publicada pela Free Software Foundation. A licena est disponvel em http://www.gnu.org/licenses/gfdl.txt.

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 gura 1 ilustra a arquitetura geral de um sistema de computao tpico. Nela, podemos observar elementos de hardware, o sistema operacional e alguns programas aplicativos.

Figura 1: Estrutura de um sistema de computao tpico 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

O acesso aos recursos de hardware de um sistema de computao pode ser trabalhoso e complicado, devido s caractersticas especcas de cada dispositivo fsico e a complexidade de sua interface. Por exemplo, a seqncia 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); 2

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 interface de baixo nvel, para simplicar a construo de programas aplicativos. Por exemplo: para ler dados de um disco rgido, uma aplicao usa uma abstrao chamada arquivo, 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 a controladora 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 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 usando a abstrao de arquivo, sem levar em conta onde esto os dados reais: num disquete, num disco IDE, num disco SCSI, numa mquina fotogrca digital conectada porta USB, num CD ou num 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 3

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 dos recursos do hardware se faz necessria: Cada computador possui normalmente um s processador. O uso desse processador 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 outros. 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 seqencial (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 10.000 conexes simultneas em um servidor de e-mail POP3, um atacante pode puxar para si todos os recursos do servidor (processos, conexes de rede, memria e processador), fazendo com que os demais usurios no sejam mais atendidos. Cabe ao 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 hardware e gerenciar seus recursos, provendo aos aplicativos um ambiente de execuo abstrato, no qual o acesso aos recursos de hardware se faz atravs de interfaces simples, independentes das caractersticas de baixo nvel do hardware, e no qual os conitos no uso do hardware so minimizados.

2 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 um programa aps o outro, processando-os em seqncia, o que permitia um alto grau de utilizao do sistema. Ainda hoje o termo em lote usado para designar um conjunto 4

de comandos que deve ser executado em seqncia, 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 [TKvRB91] e Clouds [DRJLAR91], 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. Sua principais caractersticas so a interface grca, o suporte interatividade e a operao em rede. Exemplos de sistemas desktop so o Windows XP, 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. Embutido : um sistema operacional dito embutido (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, controladores industriais e automotivos, equipamentos eletrnicos de uso domstico (leitores de DVD, TVs, fornos-micro-ondas, centrais de alarme, etc). Muitas vezes um sistema operacional embutido de apresenta na forma de uma biblioteca a ser ligada ao programa da aplicao (que xa). Exemplos de sistemas operacionais embutidos so o C/OS, Xylinx, LynxOS e VxWorks. 5

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 conseqncias 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 embutidos tm caractersticas de tempo real, e vice-versa.

3 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 essa 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 forma justa1 entre as aplicaes, evitando que uma aplicao monopolize esse recurso e respeitando as prioridades dos usurios. Busca-se criar a abstrao de um processador para cada tarefa, que facilita a vida 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 um espao de memria prprio, independente e isolado dos demais, inclusive do ncleo do sistema. Caso a memria RAM no seja suciente, o sistema deve prover armazenamento secundrio (espao em disco) como complemento de memria, de forma transparente s aplicaes. A principal abstrao construda pela gerncia de memria a noo de memria virtual, que desvincula o espao de endereos visto por cada
1 Distribuir de forma justa, mas no necessariamente igual, pois as aplicaes tm demandas de processamento distintas; por exemplo, um navegador de Internet demanda muito menos o processador que um aplicativo de edio de vdeo.

aplicao dos respectivos espaos de armazenamento providos pela RAM e pelos discos. Com isso, os programadores podem construir suas aplicaes sem se preocupar com os endereos de memria onde elas iro 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 as abstraes de arquivo e diretrio, denindo tambm sua interface de acesso e as regras para seu uso. importante observar que essas abstraes so to importantes e difundidas que muitos sistemas operacionais as usam para permitir o acesso a recursos que nada tem a ver com armazenamento, como 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), informaes do ncleo do sistema (como o diretrio /proc do UNIX) ou mesmo para abstrair todos os recursos do sistema (como faz o sistema operacional Plan 9 [PPT+ 93], para o qual todos os recursos 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 sero 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 [SGG01, Tan03] representam a estrutura do sistema operacional conforme indicado na gura 2. Nela, o ncleo central implementa o acesso de baixo nvel ao hardware, enquanto os mdulos externos representam as vrias funcionalidades do sistema.

Figura 2: Funcionalidades do sistema operacional Uma regra importante a ser observada na construo de um sistema operacional2 a separao entre os conceitos de poltica e mecanismo. Como poltica consideram-se os aspectos de deciso mais abstratos, que podem ser resolvidos por algoritmos de nvel 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, etc) sem ter de mexer no cdigo que interage diretamente com o hardware. Alguns sistemas, como o InfoKernel [ADADB+ 03], permitem s aplicaes escolher as polticas do sistema mais adequadas para suas necessidades.
Na verdade essa regra to importante que deveria ser levada em conta na construo de qualquer sistema complexo.
2

4 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 binria 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 se relacionam entre si conforme apresentado na gura 3. A forma como esses diversos componentes so interligados e se relacionam varia de sistema para sistema; algumas possibilidades sero discutidas na seo 6.

5 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. 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 idia de programa armazenado, ou seja, o programa a ser executado reside na memria junto com os dados. Os 9

Figura 3: Estrutura de um sistema operacional principais elementos constituintes do computador (processador, memria e controladores de perifricos) esto interligados por um ou mais barramentos (para a transferncia de dados, endereos e sinais de controle). A gura 4 ilustra a arquitetura de um computador tpico.

Figura 4: 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 10

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). 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, a controladora USB permite acesso ao mouse, teclado e outros dispositivos USB externos. Para o processador, cada dispositivo representado por sua controladora, que pode ser acessada em uma determinada faixa de endereos de entrada/sada. A tabela a seguir apresenta alguns endereos de acesso a controladoras em um PC tpico: 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 IRQ 1 14 15 3 5

5.1 Interrupes e excees

Um mecanismo muito utilizado na interao entre o processador e os controladores de perifricos (incluindo a MMU) de importncia fundamental para a construo de sistema operacionais: as interrupes. Esse mecanismo ser brevemente descrito nesta seo. Quando um controlador de perifrico possui 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);

11

 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 gura 5 representa os principais passos associados ao tratamento de uma interrupo envolvendo a placa de rede Ethernet, enumerados a seguir:

Figura 5: Roteiro tpico de um tratamento de interrupo 1. O processador est executando um programa qualquer (em outras palavras, um uxo de execuo); 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; 12

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, algumas interrupes podem ser mascaradas pelo processador, ou seja, ele pode ignor-las temporariamente, se necessrio. 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, ou traps. 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 o mesmo vetor de endereos de funes). A tabela 1 representa o vetor de interrupes do processador Intel Pentium (extrada de [PH05]). 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 13

Tabela 1: Vetor de Interrupes do processador Pentium [PH05] 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)

tratados. Alm disso, as interrupes permitem construir funes de entrada/sada assncronas, ou seja, que dispensam o processador de 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 intermedia todos os acessos ao hardware. Mas como impedir as aplicaes de acessar o hardware diretamente?

14

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 (arquivos, diretrios, reas de memria, etc). Para permitir a diferenciao de privilgio de acesso entre os 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 a mudana de um nvel de execuo para outro controlada por condies especcas. 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 registradores, portas de entrada/sada e reas de memria podem ser acessados em leitura e escrita. 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 gura 6. Todavia, essa separao nem sempre segue uma regra to simples; outras opes de organizao de sistemas operacionais sero abordadas na seo 6.

15

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 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 em um mecanismo j apresentado na seo 5.1: as interrupes e excees. 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. 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. A gura 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: 16

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. Alternativamente, a rotina de tratamento da interrupo de software pode passar o controle para a gerncia de atividades ao invs de retornar diretamente da interrupo de software. 9. Na seqncia, a gerncia de atividades pode devolver o controle a outra aplicao que tambm esteja aguardando o retorno de uma interrupo de software. A maioria dos sistemas operacionais implementa centenas ou mesmo milhares de chamadas de sistema, 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 [Gal94], que dene um padro de interface de ncleo para sistemas UNIX.

6 Arquiteturas de Sistemas Operacionais

Embora a denio de nveis de privilgio (seo 5.3) imponha uma estruturao mnima a um sistema operacional, as mltiplas 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. 17

Figura 7: Roteiro tpico de uma chamada de sistema

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 gura 8 ilustra essa arquitetura.

Figura 8: Uma arquitetura monoltica A grande vantagem dessa arquitetura seu desempenho: qualquer componente do ncleo pode acessar os demais componentes, toda a memria ou mesmo dispositivos

18

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 em na estrutura de dados de um componente podem ter 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 embutidos usam essa arquitetura, 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) [Day83], e tambm seria de se esperar sua adoo no domnio dos sistemas operacionais. No entanto, alguns inconvenientes limitam sua aceitao nesse contexto: 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 [CV65]. 19

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 gura 9 ilustra essa abordagem.

Figura 9: Viso geral de uma arquitetura micro-ncleo 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. Todas as mensagens so transmitidas atravs de servios do micro-ncleo, como mostra a gura 9. Como os processos tm de solicitar servios uns dos outros (para poder realizar suas incumbncias), 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 [RJO+ 89] e Chorus [RAA+ 92]. 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 alastre ao restante do 20

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 embutidos e de tempo-real.

6.4 Mquinas virtuais

Uma mquina virtual denida em [PG74] como uma duplicata eciente e isolada de uma mquina real. Em uma mquina real, uma camada de software de baixo nvel (por exemplo, a BIOS dos sistemas PC) fornece acesso aos vrios recursos do hardware para o sistema operacional, que os disponibiliza de forma abstrata s aplicaes. Em uma mquina real, quando o sistema operacional acessa os dispositivos de hardware, ele faz uso dos drivers respectivos, que interagem diretamente com a memria e os dispositivos da mquina. Um emulador o oposto da mquina real. O emulador implementa todas as instrues realizadas pela mquina real em um ambiente abstrato, possibilitando executar um aplicativo de uma plataforma em outra, por exemplo, um aplicativo do Windows executando no Linux. Infelizmente, um emulador perde muito em ecincia ao traduzir cada instruo da mquina real. Alm disso, emuladores so bastante complexos, pois geralmente necessitam simular a quase totalidade das instrues do processador e demais caractersticas do hardware que os circundam [Mal73]. A funcionalidade e o nvel de abstrao de uma mquina virtual encontra-se entre uma mquina real e um emulador, na medida em que abstrai somente os recursos de hardware e de controle usados pelas aplicaes. Uma mquina virtual um ambiente criado por um monitor de mquinas virtuais, tambm denominado sistema operacional para sistemas operacionais [KF91]. O monitor pode criar uma ou mais mquinas virtuais sobre uma nica mquina real. Enquanto um emulador fornece uma camada de abstrao completa entre o sistema em execuo e o hardware, um monitor abstrai o hardware subjacente e controla uma ou mais mquinas virtuais. Cada mquina virtual fornece facilidades para uma aplicao ou um sistema convidado que acredita estar executando sobre um ambiente normal com acesso fsico ao hardware. Existem basicamente duas abordagens para a construo de sistemas de mquinas virtuais: o tipo I, onde o monitor de mquinas virtuais implementado entre o hardware e os sistemas convidados, e o tipo II, onde o monitor implementado como um processo de um sistema operacional real subjacente, denominado sistema antrio ou sistema hospedeiro. Ambas as abordagens esto ilustradas na gura 10. Como exemplos

21

de sistemas de tipo I podem ser citados o VMWare ESX Server e o Xen; para o tipo II podem ser citados o VMWare Workstation, o MS Virtual PC e o User-Mode Linux.

Figura 10: Mquinas virtuais de tipo I (esquerda) e de tipo II (direita) Como o sistema operacional convidado e o ambiente de execuo na 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. As mquinas virtuais tm recebido bastante destaque nos ltimos anos, sobretudo devido ao grande sucesso de linguagens independentes de plataforma como Java. Todavia, a mquina virtual Java (JVM Java Virtual Machine) deve ser considerada basicamente um emulador, na medida em que cria um ambiente de execuo abstrato para aplicaes Java. Programas em linguagem Java so compilados em bytecodes, que so basicamente cdigo de mquina para um processador abstrato. Assim, a JVM somente executa aplicaes construdas especicamente para essa mquina hipottica. Outros emuladores populares so o QEmu e o Bochs. Os trabalhos [Gol73, Blu02] 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;

22

 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 [Dik00, Blu02]. Todavia, pesquisas recentes tm obtido a reduo desse custo a patamares abaixo de 20%, graas sobretudo a ajustes no cdigo do sistema hospedeiro [KDC03]. Esse problema no existe em ambientes cujo hardware suporta o conceito de virtualizao, como o caso dos mainframes.

7 Um breve histrico dos sistemas operacionais

Os primeiros sistemas de computao, no nal dos anos 40 e incio dos anos 50, no possuiam 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 [Fou05]: 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 de 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 [CDD62], 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. 23

1965 : Um projeto conjunto entre MIT, GE e Bell Labs dene o sistema operacional Multics, cujas idias 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 kernel 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. a completar... 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.

24

Questes
1. Quais os dois principais objetivos dos sistemas operacionais? 2. Por que a abstrao de recursos importante para os desenvolvedores de aplicaes? Ela tem utilidade para os desenvolvedores do prprio sistema operacional? 3. A gerncia de atividades permite compartilhar o processador, executando mais de uma aplicao ao mesmo tempo. Identique as principais vantagens trazidas por essa funcionalidade e os desaos a resolver para implement-la. 4. O que caracteriza um sistema operacional de tempo real? Quais as duas classicaes de sistemas operacionais de tempo real e suas diferenas? 5. Relacione as armaes aos respectivos tipos de sistemas operacionais: distribudo (D), multi-usurio (M), desktop (K), servidor (S), embutido (E) ou de tempo-real (T): (a) Deve ter um comportamento temporal previsvel, ou seja, com prazos de resposta bem denidos. (b) A localizao dos recursos do sistema transparente para os usurios. (c) Todos os recursos do sistema tm proprietrios e existem regras controlando o acesso aos mesmos pelos usurios. (d) A gerncia de energia muito importante neste tipo de sistema. (e) Prioriza a gerncia da interface grca, recursos multimdia e a interao com o usurio. (f) Construdo para gerenciar de forma eciente grandes volumes de recursos. (g) So sistema operacionais compactos, construdos para executar sobre plataformas com poucos recursos. 6. A operao em modo usurio permite ao processador executar somente parte das instrues disponveis em seu conjunto de instrues. Quais das seguintes operaes no deveria ser permitida em nvel usurio? Por que? (a) Ler uma porta de entrada/sada (b) Efetuar uma diviso inteira (c) Escrever um valor em uma posio de memria (d) Ajustar o valor do relgio do hardware (e) Ler o valor dos registradores do processador (f) Mascarar uma ou mais interrupes 25

7. O que diferencia o ncleo do restante do sistema operacional? 8. Seria possvel construir um sistema operacional seguro usando um processador que no tenha nveis de privilgio? Por que? 9. Coloque na ordem correta as aes abaixo, que ocorrem durante a execuo da funo printf("Hello world\n") por um processo (observe que algumas dessas aes podem ou no fazer parte da seqncia). (a) A rotina de tratamento da interrupo de software, dentro do kernel, ativada. (b) Os valores de retorno da chamada de sistema so devolvidos ao processo. (c) A funo da biblioteca processa os parmetros de entrada Hello world\n. (d) A funo printf ajusta os registradores para solicitar a chamada de sistema write() (e) O disco gera uma interrupo indicando a concluso da operao. (f) O escalonador escolhe o processo mais prioritrio. (g) Uma interrupo de software executada. (h) O processo chama a funo printf() da biblioteca do sistema (i) A operao de escrita no terminal agendada pela rotina da interrupo. (j) O controle volta para a funo printf, em modo usurio. 10. Indique quais das seguintes operaes teriam de ser implementadas por chamadas de sistema, justicando suas respostas: (a) Ler o relgio do hardware (b) Enviar um pacote de rede (c) Calcular um logartmo natural (d) Obter um nmero aleatrio (e) Remover um arquivo 11. O processador Pentium possui dois bits para denir o nvel de privilgio, resultando em 4 nveis distintos. A maioria dos sistemas operacionais para esse processador usa somente os nveis extremos (0 e 3, ou 002 e 112). Haveria alguma utilidade para os nveis intermedirios? 12. Quais as diferenas entre interrupes, excees e traps? 13. Quais as implicaes de mascarar interrupes? O que pode ocorrer se o processador ignorar interrupes por muito tempo? O que poderia ser feito para evitar o mascaramento de interrupes? 26

14. O comando em linguagem C fopen uma chamada de sistema ou uma funo de biblioteca? Por que? 15. Monte uma tabela com os benefcios e decincias mais signicativos das principais arquiteturas de sistemas operacionais. 16. O Linux possui um ncleo similar com o da gura 8, mas tambm possui tarefas de ncleo que executam como os gerentes da gura 9. Seu ncleo monoltico ou micro-ncleo? Por que?

Projetos
1. O utilitrio strace do UNIX permite observar a seqncia de chamadas de sistema efetuadas por uma aplicao. Em um terminal UNIX, execute strace date para descobrir quais os arquivos abertos pela execuo do utilitrio date (que indica a data e hora correntes). Por que o utilitrio date precisa fazer chamadas de sistema? 2. O utilitrio ltrace do UNIX permite observar a seqncia de chamadas de biblioteca efetuadas por uma aplicao. Em um terminal UNIX, execute ltrace date para descobrir as funes de biblioteca chamadas pela execuo do utilitrio date (que indica a data e hora correntes). Pode ser observada alguma relao entre as chamadas de biblioteca e as chamadas de sistema observadas no tem anterior?

Referncias
[ADADB+ 03] Andrea Arpaci-Dusseau, Remzi Arpaci-Dusseau, Nathan Burnett, Timothy Denehy, Thomas Engle, Haryadi Gunawi, James Nugent, and Florentina Popovici. Transforming policies into mechanisms with InfoKernel. In 19th ACM Symposium on Operating Systems Principles, October 2003. [Blu02] [CDD62] [CV65] [Day83] Bill Blunden. Virtual Machine Design and Implementation in C/C++. Worldware Publishing, 2002. F. Corbat, M. Daggett, and R. Daley. An experimental time-sharing system. In Proceedings of the Spring Joint Computer Conference, 1962. F. J. Corbat and V. A. Vyssotsky. Introduction and overview of the Multics system. In AFIPS Conference Proceedings, pages 185196, 1965. John Day. The OSI reference model. Proceedings of the IEEE, December 1983.

27

[Dik00]

Je Dike. A user-mode port of the Linux kernel. In Proceedings of the 4th Annual Linux Showcase & Conference, 2000.

[DRJLAR91] Partha Dasgupta, Jr. Richard J. LeBlanc, Mustaque Ahamad, and Umakishore Ramachandran. The Clouds distributed operating system. Computer, 24(11):3444, November 1991. [Fou05] [Gal94] [Gol73] [KDC03] Wikimedia Foundation. http://www.wikipedia.org, 2005. Wikipedia online enciclopedia.

Bill Gallmeister. POSIX.4: Programming for the Real World. OReilly, 1994. R. Goldberg. Architecture of virtual machines. In AFIPS National Computer Conference, 1973. Samuel King, George Dunlap, and Peter Chen. Operating system support for virtual machines. In Proceedings of the USENIX Technical Conference, 2003. Nancy Kelem and Richard Feiertag. A separation model for virtual machine monitors. In Proceedings of the IEEE Symposium on Security and Privacy, pages 7886, 1991. Efrem Mallach. On the relationship between virtual machines and emulators. In Workshop on Virtual Computer Systems, pages 117126, 1973. Gerald Popek and Robert Goldberg. Formal requirements for virtualizable third generation architectures. Communications of the ACM, 17(7):412 421, July 1974. David Patterson and John Henessy. Organizao e Projeto de Computadores. Campus, 2005. Rob Pike, Dave Presotto, Ken Thompson, Howard Trickey, and Phil Winterbottom. The use of name spaces in Plan 9. Operating Systems Review, 27(2):7276, April 1993. M. Rozier, V. Abrossimov, F. Armand, I. Boule, M. Gien, M. Guillemont, F. Herrman, C. Kaiser, S. Langlois, P. Lonard, and W. Neuhauser. Overview of the Chorus distributed operating system. In Workshop on MicroKernels and Other Kernel Architectures, pages 3970, Seattle WA (USA), 1992. Richard Rashid, Daniel Julin, Douglas Orr, Richard Sanzi, Robert Baron, Alesandro Forin, David Golub, and Michael B. Jones. Mach: a system software kernel. In Proceedings of the 1989 IEEE International Conference, COMPCON, pages 176178, San Francisco, CA, USA, 1989. IEEE Comput. Soc. Press. 28

[KF91]

[Mal73] [PG74]

[PH05] [PPT+ 93]

[RAA+ 92]

[RJO+ 89]

[SGG01] [Tan03] [TKvRB91]

Abraham Silberschatz, Peter Galvin, and Greg Gane. Sistemas Operacionais Conceitos e Aplicaes. Campus, 2001. Andrew Tanenbaum. Sistemas Operacionais Modernos, 2a edio. Pearson Prentice-Hall, 2003. A. Tanenbaum, M. Kaashoek, R. van Renesse, and H. Bal. The Amoeba distributed operating system a status report. Computer Communications, 14:324335, July 1991.

29