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 especificada 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 fins 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 (distribuies Fedora e Ubuntu), compilador de texto LATEX 2 , gerenciador de referncias BibTeX, editor grfico
Inkscape, criadores de grficos 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3
3
5

Tipos de sistemas operacionais

Funcionalidades

Estrutura de um sistema operacional

10

Conceitos de hardware
5.1 Interrupes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Proteo do ncleo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Chamadas de sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11
12
15
17

Arquiteturas de Sistemas Operacionais

6.1 Sistemas monolticos . . . . . . . .
6.2 Sistemas em camadas . . . . . . . .
6.3 Sistemas micro-ncleo . . . . . . .
6.4 Mquinas virtuais . . . . . . . . . .

19
19
20
21
22

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

Um breve histrico dos sistemas operacionais

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

.
.
.
.

26

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 final 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 desafios 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 final. 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 grfica).
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 especficas 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. verificar se os parmetros informados esto corretos (nome do arquivo, identificador do leitor de disquete, buffer de leitura, etc.);
3

c Carlos Maziero

: Abstrao de recursos
editor de
textos

aplicativos

reprodutor
de mdia

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.

editor
grco

sistema operacional

hardware

discos

memria

portas
USB

rede

Figura 1: Estrutura de um sistema de computao tpico

2. verificar se o leitor de disquetes est disponvel;
3. verificar 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 buffer de memria.
Assim, o sistema operacional deve definir 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 simplificar 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 dificuldade de localizar os dados desejados
dentro do disco).
Tornar os aplicativos independentes do hardware. Ao definir 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.
Definir 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 fotogrfica 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 conflitos no
uso do hardware, quando dois ou mais aplicativos precisam dos mesmos recursos
para poder executar. Cabe ao sistema operacional definir polticas para gerenciar o uso
dos recursos de hardware pelos aplicativos, e resolver eventuais disputas e conflitos.
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 definindo
uma fila 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 conflitos no uso do hardware so minimizados.

Tipos de sistemas operacionais

Os sistemas operacionais podem ser classificados segundo diversos parmetros e

perspectivas, como tamanho, velocidade, suporte a recursos especficos, 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 fila, 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 identificao 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 grficos, navegao na Internet e reproduo de mdias simples. Suas
principais caractersticas so a interface grfica, 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 eficiente 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 fixa). 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 classificaes 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 especficas 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 insuficiente 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, definindo 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).
1

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.

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 definir claramente os recursos que cada usurio pode
acessar, as formas de acesso permitidas (leitura, escrita, etc.) e garantir que essas
definies sejam cumpridas. Para proteger os recursos do sistema contra acessos
indevidos, necessrio: a) definir usurios e grupos de usurios; b) identificar os
usurios que se conectam ao sistema, atravs de procedimentos de autenticao;
c) definir 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 finalmente d) registrar o uso dos recursos pelos
usurios, para fins 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 grfica, suporte de rede, fluxos 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

gerncia de
memria

suporte
de rede

gerncia de
dispositivos
ncleo

gerncia de
proteo

gerncia de
arquivos
interface
grca

etc

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
2

Na verdade essa regra to importante que deveria ser levada em conta na construo de qualquer
sistema computacional complexo.

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
especificaes 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
suficientemente genricos para suportar mudanas de poltica sem necessidade de
modificaes. Essa separao entre os conceitos de poltica e mecanismo traz uma grande
flexibilidade aos sistemas operacionais, permitindo alterar sua personalidade (sistemas
mais interativos ou mais eficientes) 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 especficos 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 configur-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, configurao de dispositivos, manipulao de arquivos (mover,
copiar, apagar), interpretador de comandos, terminal, interface grfica, 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 definida 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, flags de status, etc.).

11

c Carlos Maziero

: Interrupes

Memria

processador

MMU

mouse

teclado

controladora
USB

monitor

unidade
de disco

conexo
de rede

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 especfico (que
pode estar fisicamente 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 especficos 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
Notificar 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
fluxo de execuo corrente e desviam para um endereo pr-definido, 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 final 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:

programa
em execuo

Memria
1

rotina de
tratamento de
interrupo

5
6

rede
2

MMU

processador

dados

controladora
de rede

endereos

controle

Figura 5: Roteiro tpico de um tratamento de interrupo

1. O processador est executando um programa qualquer (em outras palavras, um
fluxo 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 finalizada 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 configurao
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 especfico
do processador.
Para distinguir interrupes geradas por dispositivos distintos, cada interrupo
identificada 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 define 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 fixa da memria RAM, definida pelo
fabricante do processador, ou tem sua posio indicada pelo contedo de um registrador
da CPU especfico para esse fim.
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 overflow
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
floating 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 eficiente a interao do processador com os
dispositivos perifricos. Se no existissem interrupes, o processador perderia muito
tempo varrendo todos os dispositivos do sistema para verificar 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 configur-lo e gerenci-lo, os utilitrios e os aplicativos devem ter acesso
mais restrito a ele, para no interferir nas configuraes 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 flags 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
definidas. 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 finalizado, 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,
confinados 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

nvel
usurio

: Chamadas de sistema

aplicao

nvel
ncleo

aplicao

aplicao

aplicao

ncleo

hardware

Figura 6: Separao entre o ncleo e as aplicaes

5.3

Chamadas de sistema

O confinamento de cada aplicao em sua rea de memria, imposto pelos mapeamentos de memria realizados pela MMU nos acessos em nvel usurio, prov robustez
e confiabilidade 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 especficas para entrar/sair do
modo privilegiado, como SYSCALL e SYSRET (nos processadores Pentium 64 bits) e
tambm um conjunto de registradores especficos 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 definem 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 finalizao 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, verifica a validade de cada um deles e
realiza (ou agenda para execuo posterior) a operao desejada pela aplicao.
6. Ao final 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 finaliza 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 finalidades. O conjunto de chamadas de sistema
oferecidas por um ncleo define 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 define 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

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 definio 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

nvel
usurio

: Sistemas em camadas

aplicao

aplicao

memory
operations

le
operations

aplicao

process
manager

CPU
scheduler

aplicao

network
operations

memory
manager
access
control

nvel
ncleo

network
protocols
kernel data structures

NTFS
le system

MMU
control

block I/O
operations

USB
driver

VFAT
le system

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
sofisticados. Por fim, a camada superior define 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 ficarem 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 flexibilidade: caso um sub-sistema tenha problemas, os mecanismos de proteo
de memria e nveis de privilgio iro confin-lo, impedindo que a instabilidade se
21

c Carlos Maziero

: Mquinas virtuais

user
application

user
application

user
application

aplicaes
sistema operacional

process
manager
memory
manager

MMU
control

le
system

protection
manager

network
protocols

block IO
operations
network
driver

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 flexveis: 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-definidas.
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

monitor
sistema
hospedeiro

Aplics Windows

Aplics Windows

Windows

Windows

camada de
virtualizao

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 definiram as condies necessrias
para que uma plataforma de hardware suporte de forma eficiente 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,
finalmente respeitando as condies conceituais definidas 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 especfica. 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

Aplics Linux

Aplics Windows

ncleo Linux

ncleo Windows

JVM
ncleo Linux

hipervisor

hardware x86

hardware x86

VM de aplicao

VM de sistema

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

OS 1

aplics

aplics

aplics

guest OS

OS 2
host OS

hipervisor

hipervisor

hardware

hardware

hipervisor nativo

hipervisor convidado

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 configuraes 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 reconfigurao de um

sistema operacional, provendo confiabilidade 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 final 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, fitas 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 define o sistema operacional
Multics, cujas ideias inovadoras iro influenciar 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 grfica totalmente incorporada ao sistema.
1985 : primeira tentativa da Microsoft no campo dos sistemas operacionais com interface
grfica, atravs do MS-Windows 1.0.
1987 : Andrew Tanenbaum, um professor de computao holands, desenvolve um
sistema operacional didtico simplificado, 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 finlands, 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 reflete 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