SISTEMAS OPERACIONAIS

Prévia do material em texto

T164s Tanenbaum, Andrewa S.
 Sistemas operacionais [recurso eletrônico] : projeto e
 implementação / Andrew S. Tanenbaum, Albert S. Woodhull ;
 tradução João Tortello. – 3. ed. – Dados eletrônicos. – Porto
 Alegre : Bookman, 2008.
 Editado também como livro impresso em 2008.
 ISBN 978-85-7780-285-2
 1. Sistemas operacionais. I. Woodhull, Albert S. II. Título.
 CDU 004.4
Catalogação na publicação: Mônica Ballejo Canto – CRB 10/1023
3
ENTRADA/SAÍDA
Uma das principais funções de um sistema operacional é controlar todos os dispositivos de 
E/S (Entrada/Saída) do computador. Ele precisa enviar comandos para os dispositivos, cap-
turar interrupções e tratar de erros. Também deve fornecer uma interface simples e fácil de 
usar entre os dispositivos e o restante do sistema. Na medida do possível, a interface deve ser 
a mesma para todos os dispositivos (independência de dispositivo). O código de E/S repre-
senta uma parte signifi cativa do sistema operacional como um todo. Assim, para realmente 
entender o que um sistema operacional faz você precisa compreender como funciona a E/S. O 
modo como o sistema operacional gerencia a E/S é o principal assunto deste capítulo.
Este capítulo está organizado como segue. Primeiramente, veremos alguns dos prin-
cípios da organização do hardware de E/S. Em seguida, examinaremos o software de E/S 
em geral. O software de E/S pode ser estruturado em camadas, com cada camada tendo uma 
tarefa bem defi nida a executar. Estudaremos essas camadas para vermos o que elas fazem e 
como se encaixam.
Logo após, vem uma seção sobre impasses. Defi niremos os impasses precisamente, 
mostraremos como eles são causados, forneceremos dois modelos para analisá-los e discuti-
remos alguns algoritmos para evitar sua ocorrência.
Em seguida, passaremos a ver o MINIX 3. Começaremos com uma visão geral da E/S 
no MINIX 3, incluindo interrupções, drivers de dispositivo, E/S dependente de dispositivo 
e E/S independente de dispositivo. Depois dessa introdução, veremos vários dispositivos de 
E/S em detalhes: discos, teclados e vídeo. Para cada dispositivo, estudaremos seu hardware 
e software.
 3.1 PRINCÍPIOS DO HARDWARE DE E/S
Diferentes pessoas vêem o hardware de E/S de diferentes maneiras. Os engenheiros elétricos 
o vêem em termos de chips, fi os, fontes de alimentação, motores e todos os outros componen-
tes físicos que compõem o hardware. Os programadores vêem a interface apresentada para 
o software — os comandos aceitos pelo hardware, as funções que ele executa e os erros que 
podem ser informados. Neste livro, estamos preocupados com a programação de dispositivos 
de E/S e não com o seu projeto, construção ou manutenção; portanto, nosso interesse estará 
restrito à programação do hardware e não no seu funcionamento interno. Contudo, muitas 
vezes a programação de muitos dispositivos de E/S está intimamente ligada à sua operação 
CAPÍTULO 3 • ENTRADA/SAÍDA 217
interna. Nas próximas três subseções, ofereceremos uma breve base geral sobre hardware de 
E/S no que diz respeito à programação.
 3.1.1 Dispositivos de E/S
Grosso modo, os dispositivos de E/S podem ser divididos em duas categorias: dispositivos 
de bloco e dispositivos de caractere. Um dispositivo de bloco armazena informações em 
blocos de tamanho fi xo, cada um com seu próprio endereço. Os tamanhos de bloco comuns 
variam de 512 a 32.768 bytes. A propriedade fundamental de um dispositivo de bloco é que 
é possível ler ou escrever cada bloco independentemente de todos os outros. Os discos são os 
dispositivos de bloco mais comuns.
Se você olhar de perto, não há uma divisão clara entre os dispositivos que são endereçá-
veis por blocos e os que não são. Todo mundo concorda que um disco é um dispositivo ende-
reçável por blocos porque, independente de onde esteja o braço do disco em dado momento, 
sempre é possível buscar outro cilindro e, então, esperar que o bloco solicitado passe sob o 
cabeçote. Agora, considere uma unidade de fi ta usada para fazer backups de disco. As fi tas 
contêm uma seqüência de blocos. Se a unidade de fi ta receber um comando para ler o bloco 
N, ela sempre poderá retroceder e avançar a fi ta até chegar a esse bloco. Essa operação é aná-
loga a um disco fazendo uma busca, exceto que demora muito mais. Além disso, pode ou não 
ser possível reescrever um bloco no meio de uma fi ta. Mesmo que fosse possível usar fi tas 
como dispositivos de bloco de acesso aleatório, isso seria forçar a sua natureza: normalmente, 
elas não são utilizadas dessa maneira.
O outro tipo de dispositivo de E/S é o dispositivo de caractere. Um dispositivo de carac-
tere envia ou aceita um fl uxo de caracteres, sem considerar nenhuma estrutura de bloco. Ele 
não é endereçável e não tem nenhuma operação de busca. As impressoras, interfaces de rede, 
mouses (para apontar) e a maioria dos outros dispositivos que não são do tipo disco podem 
ser vistos como dispositivos de caractere.
Essa classifi cação não é perfeita. Alguns dispositivos simplesmente não se encaixam. 
Os relógios, por exemplo, não são endereçáveis por bloco. Tampouco eles geram ou aceitam 
fl uxos de caracteres. Tudo que eles fazem é causar interrupções em intervalos bem defi nidos. 
Apesar disso, o modelo de dispositivos de bloco e de caractere é geral o sufi ciente para poder 
ser utilizado como base para fazer uma parte do software do sistema operacional tratar com 
E/S independente de dispositivo. O sistema de arquivos, por exemplo, trata somente com 
dispositivos de bloco abstratos e deixa a parte dependente de dispositivo para um software de 
nível mais baixo, chamado driver de dispositivo.
Os dispositivos de E/S têm uma variação enorme em suas velocidades, o que impõe 
uma pressão considerável no software para funcionar bem com diferentes taxas de dados. 
A Figura 3-1 mostra as taxas de dados de alguns dispositivos comuns. A maior parte desses 
dispositivos tende a fi car mais rápida à medida que o tempo passa.
 3.1.2 Controladoras de dispositivo
Normalmente, as unidades de E/S consistem em um componente mecânico e um componente 
eletrônico. Freqüentemente é possível separar as duas partes para fornecer um projeto mais 
modular e geral. O componente eletrônico é chamado de controladora de dispositivo ou 
adaptador. Nos computadores pessoais, ele freqüentemente assume a forma de uma placa de 
circuito impresso que pode ser inserida em um slot de expansão. O componente mecânico é o 
dispositivo em si. Essa organização aparece na Figura 3-2
Normalmente, a placa controladora contém um conector, no qual pode ser ligado um 
cabo que vai até o dispositivo em si. Muitas controladoras podem manipular dois, quatro ou 
218 SISTEMAS OPERACIONAIS
até oito dispositivos idênticos. Se a interface entre a controladora e o dispositivo for padro-
nizada, como uma interface ANSI, IEEE ou um padrão ISO ofi cial, ou de fato, então as em-
presas poderão fazer controladores ou dispositivos que se encaixem nessa interface. Muitas 
empresas, por exemplo, produzem unidades de disco que combinam com as interfaces IDE 
(Integrated Drive Electronics) e SCSI (Small Computer System Interface).
Mencionamos essa distinção entre controladora e dispositivo porque o sistema opera-
cional quase sempre lida com a controladora e não com o dispositivo. A maioria dos compu-
tadores pessoais e dos servidores utiliza o modelo de barramento da Figura 3-2 para comu-
nicação entre a CPU e as controladoras. Os computadores de grande porte freqüentemente 
utilizam um modelo diferente, com computadores de E/S especializados, chamados canais 
de E/S, que assumem parte da carga da CPU principal.
Monitor
Teclado USBCD-ROM
Unidade de
disco rígido
Controladora
de disco
rígido
Controladora
USB
Controladora
de teclado
Controladora
de vídeoMemóriaCPU
Barramento
Figura 3-2 Um modelo para conectar a CPU, a memória, as controladoras e os dispositivos 
de E/S.
Dispositivo Taxa de dados
Teclado 10 bytes/s
Mouse 100 bytes/s
Modem de 56K 7 KB/s
Scanner 400 KB/s
Camcorderdigital 4 MB/s
CD-ROM de 52x 8 MB/s
FireWire (IEEE 1394) 50 MB/s
USB 2.0 60 MB/s
Monitor XGA 60 MB/s
Rede SONET OC-12 78 MB/s
Gigabit Ethernet 125 MB/s
Disco serial ATA 200 MB/s
Disco SCSI Ultrawide 4 320 MB/s
Barramento PCI 528 MB/s
Figura 3-1 Algumas taxas de dados típicas de dispositivo, rede e barramento.
CAPÍTULO 3 • ENTRADA/SAÍDA 219
Freqüentemente, a interface entre a controladora e o dispositivo é de baixo nível. Um 
disco, por exemplo, poderia ser formatado com 1024 setores de 512 bytes por trilha. Entre-
tanto, o que realmente sai da unidade de disco é um fl uxo serial de bits, começando com um 
preâmbulo, seguido dos 4096 bits de um setor (512 × 8 bits) e, fi nalmente, uma soma de 
verifi cação, também chamada de Código de Correção de Erros (ECC – Error-Correcting 
Code). O preâmbulo é gravado quando o disco é formatado e contém o número do cilindro e 
do setor, o tamanho do setor e dados similares.
A tarefa da controladora é converter o fl uxo serial de bits em um bloco de bytes e 
realizar toda correção de erro necessária. Normalmente, o bloco de bytes é primeiramente 
montado, bit a bit, em um buffer dentro da controladora. Depois que sua soma de verifi cação 
tiver sido verifi cada e o bloco declarado como livre de erros, ele poderá então ser copiado na 
memória principal.
A controladora de um monitor também funciona como um dispositivo serial de bits, 
em um nível igualmente baixo. Ela lê na memória os bytes que contêm os caracteres a serem 
exibidos e gera os sinais usados para modular o feixe de elétrons do tubo de raios catódicos 
(CRT). A controladora também gera os sinais para fazer um feixe CRT realizar o retraço ho-
rizontal, após ele ter terminado uma linha de varredura, assim como os sinais para fazer um 
retraço vertical, após a tela inteira ter sido varrida. Em uma tela LCD esses sinais selecionam 
pixels individuais e controlam seu brilho, simulando o efeito do feixe de elétrons de um CRT. 
Se não fosse a controladora de vídeo, o programador de sistema operacional teria de progra-
mar a varredura explicitamente. Com ela, o sistema operacional inicializa a controladora com 
alguns parâmetros, como o número de caracteres ou pixels por linha e o número de linhas por 
tela, e deixa que ela se encarregue de fazer a exibição.
As controladoras de alguns dispositivos, especialmente a dos discos, estão se tornando 
extremamente sofi sticadas. Por exemplo, as controladoras de disco modernas freqüentemen-
te têm internamente vários megabytes de memória. Como resultado, quando uma leitura 
está sendo processada, assim que o braço chega ao cilindro correto, a controladora começa 
a ler e armazenar dados, mesmo que ainda não tenha chegado ao setor necessário. Esses da-
dos colocados na cache podem ser úteis para atender requisições subseqüentes. Além disso, 
mesmo após os dados solicitados serem obtidos, a controladora pode continuar a colocar 
na cache dados de setores subseqüentes, pois eles provavelmente serão necessários poste-
riormente. Dessa maneira, muitas leituras de disco podem ser manipuladas sem qualquer 
atividade do disco.
 3.1.3 E/S mapeada em memória
Cada controladora tem alguns registradores utilizados para comunicação com a CPU. Escre-
vendo nesses registradores, o sistema operacional pode fazer o dispositivo enviar dados, acei-
tar dados, ligar-se ou desligar-se, ou executar alguma outra ação. Lendo esses registradores, o 
sistema operacional pode saber qual é o estado do dispositivo, se ele está pronto para aceitar 
um novo comando etc.
Além dos registradores de controle, muitos dispositivos possuem um buffer de dados 
que o sistema operacional pode ler e escrever. Por exemplo, uma maneira comum de os com-
putadores exibirem pixels na tela é por meio de uma memória RAM de vídeo (que basica-
mente é apenas um buffer de dados), disponível para programas ou para o sistema operacio-
nal escreverem.
Surge assim o problema de como a CPU se comunica com os registradores de controle 
e com os buffers de dados dos dispositivos. Existem duas alternativas. Na primeira estratégia, 
220 SISTEMAS OPERACIONAIS
cada registrador de controle recebe um número de porta de E/S, um valor inteiro de 8 ou de 
16 bits. Usando uma instrução de E/S especial, como
IN REG,PORT
a CPU pode ler o registrador de controle PORT e armazenar o resultado no registrador REG 
da CPU. Analogamente, usando
OUT PORT,REG
a CPU pode escrever o conteúdo de REG em um registrador de controle. A maioria dos pri-
meiros computadores, incluindo praticamente todos os de grande porte, como o IBM 360 e 
todos os seus sucessores, funcionavam dessa maneira.
Nesse esquema, os espaços de endereçamento da memória e da E/S são diferentes, 
como se vê na Figura 3-3(a).
Um espaço de
endereçamentoDois endereços
Dois espaços
de endereçamento
Memória
Portas de E/S
0xFFFF…
0
(a) (b) (c)
Figura 3-3 (a) Espaço de E/S e de memória separados. (b) E/S mapeada em memória. (c) 
Misto.
Em outros computadores, os registradores de E/S fazem parte do espaço de endereça-
mento normal da memória, como se vê na Figura 3-3(b). Esse esquema é chamado de E/S 
mapeada em memória e foi introduzido com o minicomputador PDP-11. Cada registrador 
de controle recebe um endereço exclusivo ao qual nenhuma memória é atribuída. Normal-
mente, os endereços atribuídos estão no topo do espaço de endereçamento. Um esquema 
misto, com buffers de dados de E/S mapeados em memória e portas de E/S separados para os 
registradores de controle, aparece na Figura 3-3(c). O Pentium usa essa arquitetura, com os 
endereços de 640K a 1M reservados para buffers de dados de dispositivo, em computadores 
compatíveis com o IBM PC, além de portas de E/S de 0 a 64K.
Como esses esquemas funcionam? Em todos os casos, quando a CPU quer ler uma 
palavra, ou da memória ou de uma porta de E/S, ela coloca o endereço necessário nas linhas 
de endereço do barramento e, então, envia um sinal READ em uma linha de controle do barra-
mento. Uma segunda linha de sinal é usada para dizer se é necessário espaço de E/S ou espa-
ço de memória. Se for espaço de memória, a memória responderá a requisição. Se for espaço 
de E/S, é o dispositivo de E/S que responderá. Se houver apenas espaço de memória (como 
na Figura 3-3(b)), todo módulo de memória e todo dispositivo de E/S compara as linhas de 
endereço com o intervalo de endereços que ele atende. Se o endereço cair em seu intervalo, 
ele responderá ao pedido. Como jamais um endereço é atribuído simultaneamente à memória 
e a um dispositivo de E/S, não há nenhuma ambigüidade e nenhum confl ito.
CAPÍTULO 3 • ENTRADA/SAÍDA 221
 3.1.4 Interrupções
Normalmente, os registradores da controladora têm um ou mais bits de status que podem ser 
testados para determinar se uma operação de saída está concluída ou se novos dados estão 
disponíveis em um dispositivo de entrada. Uma CPU pode executar um laço, sempre testando 
um bit de status, até que um dispositivo esteja pronto para aceitar ou fornecer novos dados. 
Isso é chamado de consulta seqüencial (polling) ou espera ativa (busy wait). Vimos esse 
conceito na Seção 2.2.3 como um possível método para tratar com seções críticas e, naquele 
contexto, ele foi rejeitado como algo a ser evitado na maioria das circunstâncias. No âmbito 
da E/S, onde você pode ter de esperar por um tempo muito longo para que o mundo externo 
aceite ou produza dados, a consulta seqüencial não é aceitável, exceto para sistemas dedica-
dos muito pequenos, que não executam múltiplos processos.
Além dos bits de status, muitas controladoras utilizam interrupções para informar à 
CPU quando estão prontas para ter seus registradores lidos ou escritos. Vimos na Seção 2.1.6 
como as interrupções são manipuladas pela CPU. No contexto da E/S, tudo que você precisa 
saber é que a maioria dos dispositivos de interface fornece uma saída que é logicamente igual 
ao bit de status de “operação completa” ou “dados prontos” de um registrador, mas que se 
destina a ser usada para estimular uma das linhasde pedido de interrupção (IRQ – Interrupt 
ReQuest) do barramento do sistema. Assim, quando uma operação termina, ela interrompe 
a CPU e começa a executar a rotina de tratamento de interrupção. Esse código informa ao 
sistema operacional que a E/S está concluída. O sistema operacional pode então verifi car os 
bits de status para saber se tudo correu bem e recuperar os dados resultantes ou iniciar uma 
nova tentativa.
O número de entradas na controladora de interrupção pode ser limitado; os PCs da clas-
se Pentium têm apenas 15, para dispositivos de E/S. Algumas controladoras são conectadas 
diretamente na placa-mãe do sistema; por exemplo, as controladoras de disco e teclado de um 
IBM PC. Nos sistemas mais antigos, a IRQ usada por dispositivos era confi gurado por meio 
de chaves ou jumpers associados às controladoras. Se o usuário comprasse um novo dispo-
sitivo, tinha de confi gurar a IRQ manualmente, para evitar confl itos com as IRQs existentes. 
Poucos usuários conseguiam fazer isso corretamente, o que levou a indústria a desenvolver a 
tecnologia Plug’n Play, na qual a BIOS pode atribuir IRQs automaticamente para os disposi-
tivos no momento da inicialização, evitando, assim, confl itos.
 3.1.5 Acesso direto à memória
Tenha ou não E/S mapeada em memória, a CPU de um sistema precisa endereçar as controla-
doras de dispositivo para trocar dados com elas. A CPU pode solicitar dados de uma controla-
dora de E/S um byte por vez, mas fazer isso para um dispositivo como um disco, que produz 
um bloco de dados grande, desperdiçaria muito tempo de CPU; portanto freqüentemente é 
usado um esquema diferente, chamado Acesso Direto à Memória (DMA – Direct Memory 
Access). O sistema operacional só pode usar DMA se o hardware tiver uma controladora de 
DMA, o que a maioria dos sistemas possui. Às vezes, essa controladora é integrada nas con-
troladoras de disco e em outras, mas tal projeto exige uma controladora de DMA separada 
para cada dispositivo. Mais comumente, é disponível uma única controladora de DMA (por 
exemplo, na placa-mãe) para regular as transferências dos vários dispositivos de E/S, muitas 
vezes de forma concomitante.
Não importa onde esteja localizada fi sicamente, a controladora de DMA tem acesso ao 
barramento do sistema independente da CPU, como se vê na Figura 3-4. Ela contém vários 
registradores que podem ser escritos e lidos pela CPU. Isso inclui um registrador de endere-
ços de memória, um registrador contador de bytes e um ou mais registradores de controle. Os 
222 SISTEMAS OPERACIONAIS
registradores de controle especifi cam a porta de E/S a ser usada, a direção da transferência 
(leitura ou escrita do dispositivo de E/S), a unidade de transferência (um byte ou uma palavra 
por vez) e o número de bytes a transferir em uma rajada.
CPU
Controladora
de DMA
Controladora
de disco
Memória
principal
Buffer
1. A CPU
programa a
controladora
de DMA
Interrompe
ao terminar
2. O DMA solicita
transferência para
a memória 3. Dados transferidos
Barramento
4. Sinal de
reconhecimento
Controle
Contador
Endereço
Unidade de disco
Figura 3-4 Operação de uma transferência de DMA.
Para explicarmos o funcionamento do DMA, vamos primeiro ver como ocorrem as lei-
turas de disco quando o DMA não é utilizado. Primeiramente, a controladora lê o bloco (um 
ou mais setores) da unidade de disco em série, bit por bit, até que o bloco inteiro esteja em 
seu buffer interno. Em seguida, ela calcula a soma de verifi cação para verifi car se não ocor-
reu nenhum erro de leitura. Então, a controladora causa uma interrupção. Quando o sistema 
operacional começa a executar, ele pode ler o bloco de disco do buffer da controladora, um 
byte ou palavra por vez, executando um laço, com cada iteração lendo um byte ou palavra de 
um registrador de dispositivo da controladora, armazenando-o na memória principal, incre-
mentando o endereço de memória e decrementando a contagem de itens a serem lidos até que 
ela chegue a zero.
Quando o DMA é usado, o procedimento é diferente. Primeiramente, a CPU programa 
a controladora de DMA, confi gurando seus registradores para saber o que deve transferir e 
para onde (etapa 1 na Figura 3-4). Ela também envia um comando para a controladora de 
disco, dizendo a ela para que leia dados do disco em seu buffer interno e confi ra a soma de 
verifi cação. Quando dados válidos estiverem no buffer da controladora de disco, o DMA 
poderá começar.
A controladora de DMA inicia a transferência enviando uma requisição de leitura para 
a controladora de disco pelo barramento (etapa 2). Essa requisição de leitura é semelhante as 
outras e a controladora de disco não sabe, nem se preocupa, se ele veio da CPU ou de uma 
controladora de DMA. Normalmente, o endereço de memória a ser escrita é posto nas linhas 
de endereçamento do barramento, de modo que, quando a controladora de disco busca a 
próxima palavra de seu buffer interno, ela sabe onde escrevê-la. A escrita na memória é outro 
ciclo de barramento padrão (etapa 3). Quando a escrita termina, a controladora de disco envia 
um sinal de reconhecimento (ack – acknowledgement) para a controladora de DMA, também 
pelo barramento (etapa 4). Então, a controladora de DMA incrementa o endereço de memória 
a ser usado e decrementa a contagem de bytes. Se a contagem de bytes ainda for maior do 
que 0, as etapas 2 a 4 serão repetidas, até que ela chegue a 0. Nesse ponto, a controladora 
causa uma interrupção. Quando o sistema operacional inicia, não precisa copiar o bloco na 
memória; o bloco já está lá.
CAPÍTULO 3 • ENTRADA/SAÍDA 223
Talvez você esteja se perguntando por que a controladora simplesmente não armazena 
os bytes na memória principal assim que os recebe do disco. Em outras palavras, por que ela 
precisa de um buffer interno? Existem dois motivos. Primeiramente, usando o buffer interno, 
a controladora de disco pode conferir a soma de verifi cação antes de iniciar uma transferên-
cia. Se a soma de verifi cação estiver incorreta, um erro será sinalizado e nenhuma transferên-
cia para a memória será feita.
O segundo motivo é que, uma vez iniciada uma transferência de disco, os bits continu-
arão chegando do disco a uma velocidade constante, esteja a controladora pronta para eles ou 
não. Se a controladora tentasse escrever os dados diretamente na memória, ela teria que usar 
o barramento do sistema para cada palavra transferida. Se o barramento estivesse ocupado 
por algum outro dispositivo que o estivesse usando, a controladora teria de esperar. Se a pró-
xima palavra do disco chegasse antes que a anterior tivesse sido armazenada, a controladora 
precisaria armazená-la em algum outro lugar. Se o barramento estivesse muito ocupado, a 
controladora poderia acabar armazenando muitas palavras e também tendo muita administra-
ção a fazer. Quando o bloco é colocado no buffer internamente, o barramento não é necessá-
rio até que o DMA comece; portanto, o projeto da controladora é muito mais simples, pois a 
transferência de DMA para a memória não crítica com relação ao tempo.
Nem todos os computadores utilizam DMA. O argumento contra ele é que a CPU prin-
cipal freqüentemente é muito mais rápida do que a controladora de DMA e pode fazer o 
trabalho com velocidade muito maior (quando o fator limitante não é a velocidade do dis-
positivo de E/S). Se não houver nenhum outro trabalho para ela, não tem sentido fazer a 
CPU (rápida) esperar que a controladora de DMA (lenta) termine. Além disso, livrar-se da 
controladora de DMA e fazer com que a CPU realize todo o trabalho no software signifi ca 
economia de dinheiro, o que é importante em sistemas de baixo custo ou portáteis como os 
sistemas embarcados.
 3.2 PRINCÍPIOS DO SOFTWARE DE E/S
Vamos agora deixar o hardware de E/S de lado e ver o aspecto software. Primeiramente, vere-
mos os objetivos do software de E/S e, depois, as diferentes maneiras pelas quais a E/S pode 
ser feita do ponto de vista do sistema operacional.
 3.2.1 Objetivos do software de E/S
Um conceito importanteno projeto de software de E/S é a independência de dispositivo. 
Isso signifi ca que deve ser possível escrever programas que possam acessar qualquer disposi-
tivo de E/S sem a necessidade de especifi car o dispositivo antecipadamente. Por exemplo, um 
programa que lê um arquivo como entrada deve ser capaz de ler um arquivo em um disquete, 
em um disco rígido ou em um CD-ROM, sem precisar ser modifi cado para cada dispositivo 
diferente. Analogamente, qualquer pessoa deve ser capaz de digitar um comando como
sort <input >output
e fazê-lo funcionar com a entrada proveniente de um disquete, de um disco IDE, de um 
disco SCSI ou do teclado, e ter a saída indo para qualquer tipo de disco ou para a tela. Cabe 
ao sistema operacional resolver os problemas causados pelo fato desses dispositivos serem 
diferentes e exigirem seqüências de comandos muito diferentes para operações de leitura ou 
de escrita.
Intimamente relacionado à independência de dispositivo é o objetivo da atribuição 
uniforme de nomes. O nome de um arquivo ou de um dispositivo deve ser simplesmente 
224 SISTEMAS OPERACIONAIS
uma string ou um inteiro e de modo algum deve depender do dispositivo. No UNIX e no 
MINIX 3, todos os discos podem ser integrados na hierarquia do sistema de arquivos de 
maneiras arbitrárias, de modo que o usuário não precisa saber qual nome corresponde a 
qual dispositivo. Por exemplo, um disquete pode ser montado na raiz do diretório /usr/ast/
backup, de modo que copiar um arquivo para esse diretório signifi ca copiá-lo no disquete. 
Desse modo, todos os arquivos e dispositivos são endereçados da mesma maneira: por um 
nome de caminho.
Outra questão importante para o software de E/S é o tratamento de erros. Em geral, 
os erros devem ser tratados o mais próximo do hardware possível. Se a controladora descobre 
um erro de leitura, ela mesma deve tentar corrigi-lo, se puder. Se não puder, então o driver de 
dispositivo deverá tratar dele, talvez apenas tentando ler o bloco novamente. Muitos erros são 
passageiros, como os erros de leitura causados por partículas de poeira no cabeçote de leitura, 
e desaparecerão se a operação for repetida. Somente se as camadas mais baixas não forem ca-
pazes de lidar com o problema é que as camadas mais altas devem ser informadas. Em muitos 
casos, a recuperação do erro pode ser feita de modo transparente em um nível baixo, sem que 
os níveis superiores nem mesmo saibam a respeito dele.
Outra questão importante são as transferências síncronas (com bloqueio) versus as-
síncronas (baseadas em interrupções). A maior parte da E/S física é assíncrona — a CPU 
inicia a transferência e vai fazer outra coisa, até a chegada da interrupção. Os programas de 
usuário são muito mais fáceis de escrever se as operações de E/S causam bloqueio — após 
uma chamada de sistema receive, o programa é automaticamente suspenso até que os dados 
estejam disponíveis no buffer. Cabe ao sistema operacional fazer com que as operações que, 
na verdade, são baseadas em interrupções, se pareçam com bloqueios para os programas de 
usuário.
Uma outra questão para o software de E/S é o uso de buffers. Freqüentemente, os da-
dos provenientes de um dispositivo não podem ser armazenados diretamente em seu destino 
fi nal. Por exemplo, quando um pacote vem da rede, o sistema operacional não sabe onde co-
locá-lo, até o ter armazenado em algum lugar e examiná-lo. Além disso, alguns dispositivos 
têm restrições de tempo real severas (por exemplo, os dispositivos de áudio digital) de modo 
que os dados devem ser colocados antecipadamente em um buffer de saída para desvincular a 
velocidade com que o buffer é preenchido da velocidade com que ele é esvaziado, para evitar 
a falta de dados. O uso de buffers envolve um volume de cópias considerável e freqüentemen-
te tem um impacto importante sobre o desempenho das operações de E/S.
O último conceito que mencionaremos aqui são os dispositivos que podem ser compar-
tilhados versus dispositivos dedicados. Alguns dispositivos de E/S, como os discos, podem 
ser empregados por muitos usuários ao mesmo tempo. Nenhum problema é causado pelo 
fato de vários usuários terem arquivos abertos, no mesmo disco, ao mesmo tempo. Outros 
dispositivos, como as unidades de fi ta, precisam ser dedicados a um único usuário até que ele 
tenha terminado de usá-la. Então, outro usuário pode utilizar a unidade de fi ta. Ter dois ou 
mais usuários escrevendo blocos misturados aleatoriamente na mesma fi ta defi nitivamente 
não funciona. A introdução de dispositivos dedicados (não compartilhados) também apre-
senta uma variedade de problemas, como os impasses (deadlocks). Novamente, o sistema 
operacional deve ser capaz de manipular tanto dispositivos dedicados quanto compartilhados, 
de uma maneira que evite problemas.
Freqüentemente, o software de E/S é organizado em quatro camadas, como se vê na Fi-
gura 3-5. Nas subseções a seguir, veremos cada uma delas por vez, começando com a inferior. 
A ênfase deste capítulo são os drivers de dispositivo (camada 2), mas resumiremos o restante 
do software de E/S para mostrar como as partes do sistema de E/S se encaixam.
CAPÍTULO 3 • ENTRADA/SAÍDA 225
 3.2.2 Rotinas de tratamento de interrupção
As interrupções são uma realidade desagradável; embora não possam ser evitadas. Elas de-
vem ser bem ocultadas no interior do sistema operacional, para que o mínimo possível do sis-
tema saiba a seu respeito. A melhor maneira de ocultá-las é fazer com que o driver que inicia 
uma operação de E/S seja bloqueado até que a E/S tenha terminado e a interrupção associada 
ocorra. O driver se bloquear sozinho, usando-se, por exemplo, uma instrução down em um 
semáforo, uma instrução wait em uma variável de condição, uma instrução receive em uma 
mensagem ou algo semelhante.
Quando a interrupção acontece, a função de tratamento faz o que for necessário para 
atendê-la. Então, ela pode desbloquear o driver que a iniciou. Em alguns casos, ela apenas 
completará uma instrução up em um semáforo. Em outros, executará uma instrução signal 
em uma variável de condição em um monitor. Ainda, em outros casos, ela enviará uma men-
sagem para o driver bloqueado. Em todos os casos, o efeito geral da interrupção será que 
um driver que anteriormente estava bloqueado agora poderá executar. Esse modelo funciona 
melhor se os drivers forem estruturados como processos independentes, com seus próprios 
estados, pilhas e contadores de programa.
 3.2.3 Drivers de dispositivo
Anteriormente neste capítulo, vimos que cada controlador de dispositivo possui registradores 
utilizados para fornecer comandos ou para ler seu status (ou ambos). O número de registrado-
res e a natureza dos comandos variam radicalmente de um dispositivo para outro. Por exem-
plo, um driver de mouse precisa aceitar informações do mouse dizendo quanto ele se moveu e 
quais botões estão sendo pressionados no momento. Em contraste, um driver de disco precisa 
saber a respeito de setores, trilhas, cilindros, cabeçotes, movimento do braço, propulsão do 
motor, tempos de acomodação do cabeçote e todos os outros fatores mecânicos necessários 
para fazer o disco funcionar corretamente. Obviamente, esses drivers serão muito diferentes.
Assim, cada dispositivo de E/S ligado a um computador precisa de algum código espe-
cífi co do dispositivo para controlá-lo. Esse código, chamado de driver de dispositivo, geral-
mente é escrito pelo fabricante do dispositivo e distribuído junto com ele em um CD-ROM. 
Como cada sistema operacional precisa de seus próprios drivers, os fabricantes de dispositivo 
normalmente fornecem drivers para vários sistemas operacionais populares.
Normalmente, cada driver de dispositivo manipula um tipo de dispositivo ou uma classe 
de dispositivos intimamente relacionados. Por exemplo, provavelmente seria uma boa idéia 
ter um único driver de mouse, mesmo que o sistema suporte várias marcas diferentes de mou-
se. Como outro exemplo, um driver de disco normalmente pode manipular vários discos dediferentes tamanhos e velocidades, e talvez também um CD-ROM. Por outro lado, um mouse 
e um disco são tão diferentes, que são necessários drivers diferentes.
Software de E/S em nível de usuário
Software do sistema operacional independente de dispositivo
Drivers de dispositivo
Rotinas de tratamento de interrupção
Hardware
Figura 3-5 Camadas do sistema de software de E/S.
226 SISTEMAS OPERACIONAIS
Para acessar o hardware do dispositivo (quer dizer, os registradores da controladora), 
tradicionalmente, o driver de dispositivo faz parte do núcleo do sistema. Essa estratégia ofe-
rece o melhor desempenho e a pior confi abilidade, pois um erro em qualquer driver de dis-
positivo pode derrubar o sistema inteiro. O MINIX 3 diverge desse modelo para melhorar 
a confi abilidade. Conforme veremos, no MINIX 3, cada driver de dispositivo agora é um 
processo separado em modo usuário.
Conforme mencionamos anteriormente, os sistemas operacionais normalmente classi-
fi cam os drivers como dispositivos de bloco (como os discos) ou como dispositivos de ca-
ractere (como os teclados e as impressoras). A maioria dos sistemas operacionais defi ne uma 
interface padrão que todos os drivers de bloco devem suportar e uma segunda interface pa-
drão que todos os drivers de caractere devem suportar. Essas interfaces consistem em várias 
funções que o restante do sistema operacional pode chamar para fazer o driver trabalhar.
Em termos gerais, a tarefa de um driver de dispositivo é aceitar requisições abstratas do 
software independente de dispositivo (que está acima dele) e cuidar para que as requisições 
sejam executadas. Uma requisiçõa típica para um driver de disco é ler o bloco n. Se o driver 
estiver ocioso no momento da chegada de uma requisição, ele começará a executá-la imedia-
tamente. Entretanto, se ele já estiver ocupado, normalmente colocará a nova requisição em 
uma fi la de requisições pendentes para serem tratadas assim que for possível.
O primeiro passo na execução de uma requisição de E/S é verifi car se os parâmetros de 
entrada são válidos e, caso não sejam, retornar um erro. Se a requisição for válida, o próximo 
passo será transformá-la dos termos abstratos para concretos. Para um driver de disco, isso 
signifi ca descobrir onde o bloco solicitado está realmente no disco, verifi car se o motor da 
unidade de disco está funcionando, determinar se o braço está posicionado no cilindro correto 
etc. Em resumo, o driver deve decidir quais operações da controladora são exigidas e em que 
seqüência.
Uma vez que o driver tiver determinado quais comandos deve enviar para a controlado-
ra, ele começará a executá-los, escrevendo nos registradores de dispositivo da controladora. 
As controladoras simples podem manipular apenas um comando por vez. As controladoras 
mais sofi sticadas aceitam uma lista encadeada de comandos, os quais serão executados sem a 
intervenção do sistema operacional.
Após o comando (ou comandos) ter sido executado, ocorre uma de duas situações. Em 
muitos casos, o driver de dispositivo deve esperar até que a controladora realize algum traba-
lho para ele; portanto, ele bloqueia a si mesmo até que a interrupção entre para desbloqueá-lo. 
Em outros casos, entretanto, a operação é executada rapidamente, de modo que o driver não 
precisa ser bloqueado. Como exemplo desta última situação, em algumas placas gráfi cas, 
rolar a tela exige apenas escrever alguns bytes de comando nos registradores da controladora. 
Nenhum movimento mecânico é necessário; portanto, a operação inteira pode ser concluída 
em poucos microssegundos.
No primeiro caso, o driver será desbloqueado pela ocorrência da interrupção. No se-
gundo caso, ele nunca será bloqueado. De qualquer modo, após a operação ter terminado, ele 
deve verifi car a existência de erros. Se tudo estiver correto, o driver poderá ter dados para 
passar para o software independente de dispositivo (por exemplo, um bloco que acabou de ser 
lido). Finalmente, ele retorna algumas informações de status para informar situações de er-
ros, ou não, para quem o chamou. Se houver outras requisições enfi leiradas, agora uma delas 
poderá ser selecionada e iniciada. Se nada estiver enfi leirado, o driver será bloqueado e fi cará 
aguardando a próxima requisição.
Tratar com requisições de leitura e gravação é a principal função de um driver, mas 
pode haver outros requisitos. Por exemplo, talvez o driver precise confi gurar um dispositivo 
CAPÍTULO 3 • ENTRADA/SAÍDA 227
no momento que o sistema está sendo inicializado ou na primeira vez que ele for usado. 
Além disso, pode haver necessidade de gerenciar requisitos de energia, manipular dispositi-
vos Plug ’n Play ou tratar de eventos de log.
 3.2.4 Software de E/S independente de dispositivo
Embora um trecho do software de E/S seja específi co a um dispositivo, uma grande parte dele 
é independente deste. O limite exato entre os drivers e o software independente de dispositivo 
depende do sistema, pois algumas funções que poderiam ser executadas de maneira indepen-
dente de dispositivo podem, na verdade, por efi ciência ou outros motivos, serem executadas 
nos drivers. As funções que aparecem na Figura 3-6 normalmente são executadas no software 
independente de dispositivo. No MINIX 3, a maioria do software independente de dispositivo 
faz parte do sistema de arquivos. Embora nosso estudo do sistema de arquivos seja deixado 
para o Capítulo 5, veremos, aqui, rapidamente, o software independente de dispositivo para 
darmos alguma perspectiva sobre a E/S e mostrarmos melhor onde os drivers se encaixam.
Interface uniforme para drivers de dispositivo
Buffers
Informe de erros
Alocação e liberação de dispositivos dedicados
Fornecimento de um tamanho de bloco independente de dispositivo
Figura 3-6 Funções do software de E/S independente de dispositivo.
A função básica do software independente de dispositivo é executar as funções de E/S 
comuns a todos os dispositivos e fornecer uma interface uniforme para o software em nível de 
usuário. Veremos a seguir os problemas acima com mais detalhes.
Interface uniforme para drivers de dispositivo
Um problema importante em um sistema operacional é como fazer todos os dispositivos e 
drivers de E/S parecerem mais ou menos iguais. Se discos, impressoras, monitores, teclados 
etc., tiverem todos interfaces diferentes, sempre que aparecer um novo dispositivo periférico, 
o sistema operacional deverá ser modifi cado para esse novo dispositivo. Na Figura 3-7(a), 
ilustramos simbolicamente uma situação na qual cada driver de dispositivo tem uma interface 
diferente com o sistema operacional. Em contraste, na Figura 3-7(b), mostramos um projeto 
diferente, no qual todos os drivers têm a mesma interface.
Com uma interface padrão é muito mais fácil de instalar um novo driver, desde que 
ele seja compatível com a interface existente. Isso também signifi ca que os desenvolvedores 
de drivers sabem o que é esperado deles (por exemplo, quais funções eles devem fornecer 
e quais funções do núcleo eles podem chamar). Na prática, nem todos os dispositivos são 
absolutamente idênticos, mas normalmente existe apenas um pequeno número de tipos de 
dispositivo e mesmo esses geralmente são quase idênticos. Por exemplo, até os dispositivos 
de bloco e de caractere têm muitas funções em comum.
Outro aspecto do fato de ter uma interface uniforme é o modo como os dispositivos de 
E/S são nomeados. O software independente de dispositivo cuida do mapeamento de nomes 
de dispositivo simbólicos para o driver correto. Por exemplo, no UNIX e no MINIX 3, um 
nome de dispositivo, como /dev/disk0, especifi ca exclusivamente o i-node de um arquivo 
228 SISTEMAS OPERACIONAIS
especial e esse i-node contém o número principal do dispositivo (major number), que é 
usado para localizar o driver apropriado. O i-node também contém o número secundário do 
dispositivo (minor number), que é passado como parâmetro para o driver, para especifi car 
a unidade a ser lida ou escrita. Todosos dispositivos possuem números principais e secun-
dários, e todos os drivers são acessados usando-se o número principal do dispositivo para 
selecionar o driver.
Intimamente relacionada com a atribuição de nomes está a proteção. Como o sistema 
impede que os usuários acessem dispositivos que não podem acessar? No UNIX, no MINIX 
3, e também nas versões mais recentes do Windows, como o Windows 2000 e o Windows XP, 
os dispositivos aparecem no sistema de arquivos como objetos nomeados, o que signifi ca que 
as regras de proteção normais para arquivos também se aplicam aos dispositivos de E/S. O 
administrador do sistema pode então confi gurar as permissões corretas (isto é, no UNIX, os 
bits rwx) para cada dispositivo.
Uso de buffers
O uso de buffers também é um problema tanto para dispositivos de bloco como para dis-
positivos de caractere. Para dispositivos de bloco, o hardware geralmente insiste em ler e 
escrever blocos inteiros simultaneamente, mas os processos de usuário estão livres para ler e 
escrever em unidades arbitrárias. Se um processo de usuário escrever meio bloco, o sistema 
operacional normalmente manterá esses dados em memória até que sejam escritos os dados 
restantes, momento este em que o bloco irá para o disco. Para dispositivos de caractere, os 
dados podem ser escritos mais rapidamente do que eles podem aparecer na saída, precisando 
então do uso de buffers. Uma entrada de teclado que chega antes de ser necessária também 
exige o uso de buffers.
Informe de erros
Os erros são muito mais comuns no contexto da E/S do que em qualquer outro. Quando eles 
ocorrem, o sistema operacional precisa tratar deles da melhor forma possível. Muitos erros 
são específi cos do dispositivo; portanto, apenas o driver sabe o que fazer (por exemplo, tentar 
novamente, ignorar ou gerar uma situação de pânico). Um erro típico é causado por um bloco 
de disco que foi danifi cado e não pode mais ser lido. Após o driver ter tentado ler o bloco 
certo número de vezes, ele desiste e informa o software independente de dispositivo. O modo 
como o erro é tratado a partir daí é independente do dispositivo. Se o erro ocorreu durante a 
Sistema operacional Sistema operacional
Driver de disco Driver de
impressora
Driver de teclado Driver de disco Driver de
impressora
Driver de teclado
(a) (b)
Figura 3-7 (a) Sem uma interface de driver padrão. (b) Com uma interface de driver 
padrão.
CAPÍTULO 3 • ENTRADA/SAÍDA 229
leitura de um arquivo de usuário, pode ser sufi ciente informá-lo para quem fez a chamada. 
Entretanto, se ele ocorreu durante a leitura de uma estrutura de dados fundamental para o 
sistema como, por exemplo, o bloco que contém o mapa de bits mostrando quais blocos estão 
livres, talvez o sistema operacional tenha que exibir uma mensagem de erro e terminar.
Alocando e liberando dispositivos dedicados
Alguns dispositivos, como os gravadores de CD-ROM, só podem ser usados por um único 
processo em dado momento. Cabe ao sistema operacional examinar as requisições de utili-
zação do dispositivo e aceitá-los ou rejeitá-los, dependendo de o dispositivo solicitado estar 
disponível ou não. Uma maneira simples de tratar essas requisições é exigir que os processos 
executem operações open diretamente nos arquivos especiais dos dispositivos. Se o disposi-
tivo não estiver disponível, a operação open falhará, fechando esse dispositivo dedicado e, 
então, liberando-o.
Tamanho de bloco independente de dispositivo
Nem todos os discos têm o mesmo tamanho de setor. Cabe ao software independente de 
dispositivo ocultar esse fato e fornecer um tamanho de bloco uniforme para as camadas su-
periores; por exemplo, tratando vários setores como um único bloco lógico. Desse modo, as 
camadas superiores só tratam com dispositivos abstratos, todos os quais utilizam o mesmo 
tamanho de bloco lógico, independente do tamanho do setor físico. Analogamente, alguns 
dispositivos de caractere enviam seus dados um byte por vez (por exemplo, os modems), 
enquanto outros os enviam em unidades maiores (por exemplo, as interfaces de rede). Essas 
diferenças também podem ser ocultadas.
 3.2.5 Software de E/S em espaço de usuário
Embora a maior parte do software de E/S esteja dentro do sistema operacional, uma peque-
na parte dele consiste em bibliotecas ligadas ao programas do usuário e até de programas 
inteiros executando fora do espaço de endereçamento do núcleo. As chamadas de sistema, 
incluindo as de E/S, normalmente são feitas por funções de biblioteca. Quando um programa 
em C contiver a chamada
count = write(fd, buffer, nbytes);
a função de biblioteca write será ligada ao código-objeto do usuário e contida no programa 
binário presente na memória no momento da execução. O conjunto de todas essas funções de 
biblioteca claramente faz parte do sistema de E/S.
Embora essas funções façam pouco mais do que colocar seus parâmetros no lugar apro-
priado da chamada de sistema, existem outras funções de E/S que executam um trabalho real 
adicional. Em particular, a formatação da entrada e saída é feita por função de biblioteca. Um 
exemplo da linguagem C é printf, que recebe como entrada uma string de formato e possivel-
mente algumas variáveis, constrói uma string em ASCII e, então, chama write para enviar a 
string para a saída. Como um exemplo de printf, considere a instrução
printf(“The square of %3d is %6d\n”, i, i*i);
Ela formata uma string consistindo na string de 14 caracteres “The square of ”, seguida 
do valor i como uma string de 3 caracteres e, então, da string de 4 caracteres “ is ”, depois i2 
como seis caracteres e, fi nalmente, um avanço de linha.
230 SISTEMAS OPERACIONAIS
Um exemplo de função semelhante para entrada é scanf, que lê a entrada e a armazena 
nas variáveis descritas em uma string de formato usando a mesma sintaxe de printf. A biblio-
teca de E/S padrão contém várias funções que envolvem E/S e todas são executadas como 
parte de programas de usuário.
Nem todo software de E/S em nível de usuário consiste em funções de biblioteca. Outra 
categoria importante é o sistema de spooling. O spool é uma maneira de tratar com disposi-
tivos de E/S dedicados em um sistema de multiprogramação. Considere um dispositivo com 
típico com spool: uma impressora. Embora tecnicamente seja simples permitir que qualquer 
processo de usuário abra o arquivo de caracteres especial que corresponde a impressora, su-
ponha que ele o abrisse e depois não fi zesse mais nada por várias horas. Nenhum outro pro-
cesso poderia imprimir nada.
Em vez disso, é criado um processo especial, chamado daemon, em um diretório espe-
cial, o diretório de spool. Para imprimir um arquivo, um processo primeiro gera o arquivo 
inteiro a ser impresso e o coloca no diretório de spool. Cabe ao daemon, que é o único proces-
so a ter permissão para usar o arquivo especial associado a impressora, imprimir os arquivos 
no diretório. Protegendo-se o arquivo especial contra o uso direto por parte dos usuários, o 
problema de alguém deixá-lo aberto desnecessariamente por muito tempo é eliminado.
O spool não é utilizado apenas por impressoras, mas também em várias outras situa-
ções. Por exemplo, o correio eletrônico normalmente usa um daemon. Quando uma men-
sagem é enviada, ela é na verdade colocada em um diretório de spool de correio eletrônico. 
Posteriormente, o daemon de correio tentará enviá-la realmente. Eventualmente, em um dado 
momento, pode não ser possível contatar o destinatário, nesse caso, o daemon deixa a mensa-
gem no spool, com informações de status indicando que deve ser tentado um reenvio dentro 
de alguns instantes. O daemon também pode enviar um aviso para o remetente dizendo que 
o envio da mensagem foi adiado, ou, após um atraso de algumas horas, ou alguns dias, que a 
mensagem não pôde ser entregue. Tudo isso se dá fora do sistema operacional.
A Figura 3-8 resume o sistema de E/S, mostrando as diferentes camadas e as principais 
funções de cada uma. De baixo para cima, as camadas são: o hardware, as rotinasde trata-
mento de interrupção, os drivers de dispositivo, o software independente de dispositivo e os 
processos de usuário.
Requisição
de E/S
Camada
Resposta
de E/S Funções de E/S
Faz chamada de E/S; formata a E/S; spooling
Atribuição de nomes, proteção, bloqueio,
uso de buffers, alocação
Configura registradores de dispositivo; verifica status
Desbloqueia driver ao término da E/S
Executa operação de E/S
Processo de usuário
Software independente
de dispositivo
Drivers de dispositivo
Rotinas de tratamento
de interrupção
Hardware
Figura 3-8 Camadas do sistema de E/S e as principais funções de cada uma.
As setas na Figura 3-8 mostram o fl uxo de controle. Quando um programa de usuário 
tenta ler um bloco de um arquivo, por exemplo, o sistema operacional é chamado para exe-
cutar a chamada. O software independente de dispositivo procura por esse bloco na cache 
CAPÍTULO 3 • ENTRADA/SAÍDA 231
em memória (um tipo de buffer). Se o bloco necessário não estiver lá, ele chama o driver de 
dispositivo para enviar a requisição para o hardware, para obtê-lo do disco. Então, o processo 
é bloqueado até que a operação de disco tenha terminado.
Quando a operação de disco tiver terminado, o hardware gerará uma interrupção. A 
rotina de tratamento de interrupção será executada para descobrir o que aconteceu; isto é, 
qual dispositivo quer ser atendido imediatamente. Então, ela extrai o status do dispositivo e 
desbloqueia o processo que estava esperando a conclusão da operação de E/S para permitir 
que o processo de usuário continue sua execução.
Encerra aqui o trecho do livro disponibilizado para 
esta Unidade de Aprendizagem. Na Biblioteca Virtual 
da Instituição, você encontra a obra na íntegra. 
	Capa
	Iniciais 
	Ficha catalográfica 
	Folha de rosto
	Ficha técnica 
	Os autores
	Dedicatória 
	Prefácio 
	Sumário 
	1: Introdução 
	2: Processos
	3: Entrada/saída
	4: Gerenciamento de memória 
	5: Sistema de arquivos
	6: Leituras recomendadas e bibliografia 
	Apêndice A: Instalando o minix 3
	Apêndice B: O código-fonte do minix 
	Apêndice C: Índice para os arquivos 
	Índice