Академический Документы
Профессиональный Документы
Культура Документы
OPERACIONAIS
1
SISTEMAS OPERACIONAIS
1 INTRODUÇÃO................................................................................................................................3
1.1 O que é um SO?........................................................................................................................3
1.2 SO x Empresa...........................................................................................................................3
1.3 Perspectivas de um SO.............................................................................................................4
1.4 Ecossistema...............................................................................................................................4
1.5 Gerações de Sistemas Operacionais.........................................................................................5
1.6 Tipos de Sistemas de Operacionais...........................................................................................6
1.7 Hardware...................................................................................................................................7
1.8 A carga do Sistema Operacional...............................................................................................7
1.9 Conceitos - Processos...............................................................................................................8
1.10 Conceitos - Memória..............................................................................................................9
1.11 Interpretador de Comandos.....................................................................................................9
1.12 Chamadas de Sistemas..........................................................................................................10
1.13 Organização de Sistemas Operacionais (Tipos de Projeto)..................................................11
2 GERÊNCIA DE PROCESSOS......................................................................................................13
2.1 Conceitos Básicos...................................................................................................................13
2.2 Criação de Processos..............................................................................................................14
2.3 Término de Processos.............................................................................................................15
2.4 Hierarquia de Processos..........................................................................................................15
2.5 Estados de Processos (Ciclo de Vida dos Processos)..............................................................16
2.6 Interrupções............................................................................................................................17
3 GERENCIA DE MEMÓRIA.........................................................................................................19
3.1 Gerenciador de memória.........................................................................................................19
3.2 Acesso à memória...................................................................................................................19
3.3 Problemas de Gerenciamento de Memória.............................................................................19
3.4 Gerente de Memória...............................................................................................................20
3.5 Monoprogramação..................................................................................................................20
3.6 Modelo de Multiprogramação................................................................................................21
3.7 Gerenciamento Básico - Multiprogramação...........................................................................21
3.8 Overlays..................................................................................................................................25
3.9 MEMÓRIA PAGINADA........................................................................................................25
4 Gerencia de E/S..............................................................................................................................32
4.1 Introdução...............................................................................................................................32
4.2 Esquemas de E/S.....................................................................................................................33
4.3 DMA (Direct Memory Access)...............................................................................................34
5 Sistemas de Arquivos.....................................................................................................................36
5.1 Introdução...............................................................................................................................36
1 INTRODUÇÃO
1.2 SO x Empresa
Uma analogia que pode ser feita é do SO com uma grande empresa. Uma empresa está inserida em
um ambiente onde ela terá que tratar com diversos agentes externos, aqui para exemplificar, temos:
Clientes, Fornecedores e o Governo.
Dentro da empresa cada recurso é especializado para interagir de alguma forma com um ou mais de
um destes elementos. O Depto. Comercial Faz o relacionamento com o cliente até a venda. O
Depto. técnico assume o relacionamento com esse cliente a após a venda. O Depto. de Pessoas
Gerencia os recursos humanos da empresa. Já o Depto. Financeiro é responsável pela cobrança e
pagamentos.
As empresas tendem a se dividir em áreas de especialização, essa estratégia é conhecida como
dividir para conquistar, e tem o objetivo de dividir um problema maior em partes menores, tornando
mais claro os processos internos e atendendo melhor a demanda do cliente. Observe que essa
divisão é sugerida e pode variar de empresa para empresa, o fato é que os administradores aceitam
essa divisão como uma boa prática.
Um sistema operacional pode ser visto da mesma forma. Os departamentos de uma empresa podem
ser comparados as gerências de um SO: Por exemplo o Ger. de Processos é responsável por criar os
processos e alocá-los para a CPU conforme a sua característica ou prioridade. Já o Ger. de
Memória será responsável por tratar as requisições de memória do processo como também garantir
a disponibilidade de memória para outros processos. A Ger. de E/S é acionada sempre que algum
processo precisa comunicar-se com o mundo externo, porém elementos internos do próprio SO,
podem querer também se comunicar com o mundo externo. Observe que esta é uma divisão também
sugerida, e os projetistas de sistemas operacionais tem aceito isso como uma boa forma de organizar
as rotinas do SO.
1.3 Perspectivas de um SO
O SO existe basicamente para cumprir duas missões básicas:
• Gerenciar a expectativa do usuário: atendendo a suas requisições dentro do esperado pelo
usuário;
• Gerenciar recursos do Sistema: Controlando e disponibilizando recursos para atender as
demandas dos usuários.
Maquina Estendida
O usuário quer que as suas solicitações sejam atendidas, mas não quer, de maneira alguma, saber
como isso vai ser feito. Sendo assim o usuário “preenche um formulário” e o SO se encarrega de
atender a sua solicitação. Por exemplo, um processo pode pedir: SO Abra um arquivo. Informando o
caminho do arquivo, e o local onde será guardado o descritor para o arquivo. O SO por sua vez deve
criar as condições para o que o usuário possa realizar operações sobre o arquivo aberto, desta forma
o SO através dos diferentes subsistemas deve preparar-se para eventuais solicitações do usuário para
aquele arquivo.
Gerente de Recursos
Como gerente de recursos o sistema operacional tem a função de garantir a disponibilidade dos
recursos, para que as solicitações dos processos possam ser atendidas. Muitos processos podem
solicitar uma impressão por exemplo. Porém, dada a sua natureza, a porta de impressão só pode ser
usada para atender uma requisição por vez, e sendo assim o sistema operacional deve enfileirar
essas requisições e atendê-las da maneira mais otimizada possível.
1.4 Ecossistema
1.7 Hardware
O sistema operacional que você irá desenvolver rodará sobre um hardware. Você deve conhecer os
aspectos deste hardware para que obter um melhor despenho do sistema operacional. Os principais
aspectos que você deve observar:
• CPU: O Conjunto de instruções disponíveis, registradores, mecanismos de proteção
existentes, modos de acesso à memória, modo de endereçamento dos controladores de
dispositivos, hardware de gerencia de memória.
• Memória: Memórias disponíveis no sistema, se existe armazenamento persistente. Se o
modelo de memória tem espaço separado para instrução e dados.
• E/S: Existe disponibilidade de interrupções, Controlador de interrupções, Controlador
DMA?
• Barramentos: Os barramentos são padrões de mercado. A tratativa em relação a alguns
barramentos mais importantes (ex. PCI/ISA) devem está incluída diretamente no SO
(gerencia de E/S), para outros barramentos pode-se implementar o suporte através de drivers
de dispositivo.
1.10.1 Endereçamento
A memória pode ser vista como um array de posições para armazenamento de dados e instruções.
Esse conceito foi introduzido por Von Neumann. O espaço de memória ocupado por um processo é
chamado de espaço de endereçamento, e é só nesta área que o processo poderá atuar. Aqui é
importante lembrar que as arquiteturas de 32 Bits só permitem o endereçamento de 4GB por parte
do processo. Isso também é um limite para o SO. Para quebrar esse limite na arquitetura IA32 a
Intel criou uma extensão para seus processadores chamada de PAE (Physical Address Extension),
com essa extensão os limites de 4Gb para o processo continua, mas o SO consegue agora gerenciar
até 64GB de memória.
1.10.2 Fragmentação
Uma das finalidades do SO é gerenciar memória, entenda-se por isso prover memória para
processos e também gerenciar porções livres da memória. Para o SO gerenciar cada posição de
memória seria muito caro em termos de processamento e memória. Por isso os sistemas optam por
dividir a memória em blocos, e é esses blocos que serão alocados para os processos. Em algumas
situações o processo não conseguirá usar todo espaço do bloco, provocando desperdício de
memória, a isso chamamos de fragmentação interna. Em outros casos quando o processo é obrigado
a ocupar um espaço continuo na memória, podem surgir áreas de memória entre processos que
sejam tão pequenas que não poderão ser ocupadas por nenhum processo, o que também gera
desperdício, a esse tipo de situação chamamos de fragmentação externa.
1.10.4 Proteção
O espaço de endereçamento de um processo deve ser protegido de acessos por parte de outros
processos. Em geral o sistema operacional conta com o apoio do hardware para prover esse tipo
proteção. Quando um processo tenta acessar uma memória que está fora do seu espaço de
endereçamento o hardware gera uma (exceção)interrupção e o processo é terminado imediatamente.
1.12.1 Conceitos
Uma chamada de sistema é a forma como o sistema operacional oferece os seus serviços. Em geral
quando se faz um programa, existem certas instruções que o programa em execução, aqui chamado
de processo, pode executar, como por exemplo operar com posições de memória pertencentes ao
seu espaço de endereçamento. Exemplo: um processo pode perfeitamente somar o conteúdo de duas
posições de memória e armazenar numa terceira sem precisar do Sistema Operacional, porém se
esse processo precisa armazenar isso em um arquivo, mandar via rede ou simplesmente mostrar na
tela, ele vai precisar do Sistema operacional para isso.
Como usar uma chamada de sistema?
Para usar as chamadas de sistema oferecidas por um sistema operacional é necessário conhecer a
API ou SPI do sistema operacional que define quais chamadas estão disponíveis e quais são os
parâmetros que devem ser passados. Os desenvolvedores de sistemas operacionais devem
disponibilizar a documentação desta API, se ele deseja que as pessoas façam programas para o seu
sistema. Aqui você encontra a documentação da API do Windows e Linux.
Para explicar esses conceitos utilizaremos GNU/Linux, porém eles se aplicam a qualquer sistema
operacional. Cada uma destas chamadas recebe parâmetros que devem ser colocados em
registradores específicos. Para exemplificar imagine o programa que tem as seguintes atribuições:
ler o conteúdo de um arquivo e exibi-lo na tela. Em termos de chamadas de sistema, o programa
deve ser organizado da seguinte forma: Abrir o arquivo (Open), Ler o seu conteúdo (Read) e
Escrever na saída (write), Fechar o arquivo (close) e por fim, terminar o processo (exit). No
GNU/Linux essas chamadas de sistemas tem os seguintes números:
1 – exit
3 – read
4 – write
5 – open
6 – Close
A chamada Open apresenta os parâmetros Arquivo e Modo, onde Arquivo é o nome do arquivo que
será aberto e modo é como o arquivo será aberto. O código a seguir ilustra o uso desta chamada
usando a linguagem assembly:
section .data
_start:
2.1.1 Multiprogramação
As instruções que executam na CPU devem passar obrigatoriamente pela memória RAM, sendo
assim, um processo para ser executado precisa está na RAM. Os primeiros sistemas operacionais
eram monoprogramados, isso que dizer que em um dado momento somente um processo ocuparia a
memória além do SO. Em um sistema multiprogramado, a memória poderá está ocupada por vários
processos, cada um com o seu espaço de endereçamento. A ideia desta abordagem surgiu nos SOs
da 3a geração, para resolver o problema de desperdício de tempo de CPU durante uma operação de
E/S realizada por uma tarefa, isso ocorre principalmente porquê os dispositivos de E/S são mais
lentos que a CPU. Em ambiente multiprogramado a CPU poderá ser chaveada rapidamente entre
várias tarefas, desta forma, uma situação onde o programa espera por E/S, a CPU poderá ser
entregue a outro processo evitando o desperdício de tempo de CPU.
Transição 1: Ocorre quando um processo da fila de prontos é escolhido (escalonado) para ocupar a
CPU.
Transição 2: Essa transição ocorre em consequência de uma interrupção de hardware. Um
dispositivo requer atenção. Em SOs preemptivos o relógio de hardware gera uma interrupção para
indicar que a fatia de tempo destinada ao processo acabou.
Transição 3: Ocorre quando o processo solicita algo ao sistema operacional. Por exemplo Entrada e
Saída, mais memória, etc.
Transição 4: Ocorre quando a solicitação do processo está atendida pelo SO. O processo irá ocupar
uma posição na fila de prontos.
OBS.: Observe que esta é uma sugestão do Tanenbaum e que é seguida por grande parte dos
escritores sobre o tema. O fato é que os SOs da atualidade apresentam, muitas vezes com outra
nomeclatura, em seu conjunto de estados, também esses estados sugeridos acima. Por exemplo, o
Windows apresenta além dos estados acima: Exit (marcado para ser removido da memória), New
(Ainda não foi aceito) e Suspended (pausado). Abaixo uma figura com os estados de processo do
Windows tirada desta referência citada. Observe a semelhança do ciclo Ready-Running-Blocked,
com o ciclo descrito anteriormente.
2.6 Interrupções
O termo interrupção aplica-se a um evento inesperado que provoca um desvio no fluxo de execução
atual (o processo que está usando a CPU é interrompido e o fluxo é desviado para o sistema
operacional, esse ponto de desvio faz parte do espaço de instruções do SO é conhecido como rotina
de tratamento de interrupção ou interrupt handler). Em geral o recurso de interrupção está
disponível em qualquer sistema computacional, essa é uma funcionalidade provida pelo hardware
em questão.
A interrupção pode ocorrer tanto em nível de hardware (imprevisível) ou Software (Normalmente
Previsível). A interrupção de Hardware ocorre por solicitação de algum dispositivo que necessita de
atenção imediata, como por exemplo atualização da posição do ponteiro na tela provocada por uma
movimentação do mouse. Já interrupção de Software, é provocada pelo processo e ocorre quando
um programa solicita algum serviço do sistema operacional. Anteriormente vimos que para um
processo executar uma chamada de sistema é necessário a execução da instrução int 80h, essa
instrução provoca o chaveamento do controle para o SO. Esse tipo de interrupção é conhecida na
literatura como interrupção de software e pelo fato de ser uma instrução dada pelo programador da
aplicação, podemos dizer que esse tipo de interrupção é previsível.
Para garantir que o processo que foi interrompido, retorne ao ponto de onde parou, quando esse
ocupar novamente a CPU, é necessário que o tratador de interrupção faça o salvamento do contexto
do processo que foi interrompido. Abaixo uma lista com todos os procedimentos executados por
uma rotina de tratamento de interrupção (Tanenbaum):
• Hardware Empilha o contador de Programa atual (Registrador PC);
• Hardware Carrega novo contador PC a partir do vetor de interrupção;
• Rotina de Baixo nível Salva os Registradores;
• O procedimento para tratamento de interrupção é executado (pode ser em C);
• O escalonador de processos é acionado para escolher o próximo processo que ocupará a
CPU;
• O contexto do processo escolhido é restaurado;
• O Controle é transferido para o processo escolhido.
3 GERENCIA DE MEMÓRIA
3.5 Monoprogramação
O Fato de se ter um sistema monoprogramado (um só processo na memória) não dispensa gerência.
Esse processo pode precisar crescer, ou simplesmente ocupar um maior espaço que a RAM
disponível.
Outro detalhe que pode ser percebido é que o Sistema Operacional também deve ocupar a RAM,
pois o processo sempre irá requisitar serviços ao SO, e para atendê-los, o SO deve necessariamente
está em alguma memória acessível rapidamente pela CPU.
As figuras acima ilustram três formas de disponibilizar memória física para o processo.
Na da esquerda o Sistema Operacional e Processo Compartilham a RAM.
Na do centro o Sistema Operacional em ROM e Processo em RAM → Alguns computadores têm a
capacidade de executar instruções direto da ROM.
Na da direita SO e Processo em RAM e Drivers em ROM.
3.6 Modelo de Multiprogramação
Esse modelo ajuda a entender as vantagens de se manter N processos na memória ao mesmo tempo,
baseado em seu percentual de E/S.
Se no desenvolvimento dos processos os engenheiros tivessem conseguido resolver o problema de
E/S ser invariavelmente mais lenta que a CPU, talvez os modelos de gerenciamento de memória
fossem construídos de outra forma.
O Fato é que todo o processo faz E/S e neste tempo, se não estiver disponível na memória outro
processo, a CPU ficará ociosa. Desta forma, o modelo de multiprogramação ajuda reduzir o
desperdício de tempo de CPU.
Mas qual é o grau mínimo de multiprogramação (quantos processos podem ser colocados na
memória) que pode garantir um uso efetivo (100%) de CPU?
É importante lembrar que o modelo proposto acima é ideal (o percentual de E/S sempre varia de
processo para o outro).
É comum em sistemas multiprogramados que exista vários processos sendo criados num dado
instante. Desta forma o sistema operacional deve controlar a forma como as partições deverão ser
entregue ao processo.
A primeira alternativa é manter uma fila de admissão com os processos e a medida que eles
entrarem na fila procurar uma partição vazia para acomodar esse processo. É importante lembrar
que quanto mais próximo o tamanho do processo e da partição, menor será o desperdício, a diante
discutiremos alguns algoritmos para escolha da partição. Na figura (b) podemos ver um esquema
desta técnica.
Procurar uma partição que gere o menor desperdício possível, é uma tarefa que pode requerer um
certo tempo dependendo do tamanho da quantidade de partições. Se for possível criar fila para as
partições esse tempo será reduzido, uma vez que, na criação do processo já será atribuído a ele um
tamanho de partição. Observe que esta técnica pode provocar uma espera desnecessária para o
processo uma vez que pode existir partições ociosas numa fila para processos maiores.
3.7.4 Relocação
Uma variável definida em linguagem de alto nível sempre será definida em baixo nível como um
endereço de memória. Para exemplificar podemos citar o seguinte trecho de código:
I=25;
Podemos supor que este código será traduzido em baixo nível para a seguinte trecho, em arquitetura
específica.
MOV 25, $0x0100
A instrução acima, em assembly, vai mover o literal 25 para o endereço de memória 0x0100. Agora
imagine que no modelo de particionamento esse processo poderá ser alocado em uma partição em
que o endereço 0x1000 não faça parte. Ou seja o programador ou compilador não tem a mínima
ideia onde, na memória, o código será carregado. Esse problema é conhecido como relocação de
código e existe algumas técnicas que podem resolver esse problema, uma delas, usada
anteriormente era o carregador relocador , que reescrevia as referencias à memória no executável,
de forma que este refletisse os endereços da partição que será usada pelo processo.
3.7.5 Proteção
Se por acaso algum endereço não pertencente ao espaço de endereçamento do processo for acessado
pelo mesmo, isso será considerado uma falha de proteção. A seguir veremos as soluções disponíveis
para resolver estes dois problemas.
Para fins didáticos a figura acima ilustra uma memória de 64K com 16 partições de 4k. A idéia é
descrever como funciona a proteção usando a PSW. Observe que temos 2 instruções, a primeira (A)
acessa o endereço 0x0100 (256) do segmento, A segunda (B) o endereço 0x1000 (4096).
No exemplo a instrução pertence a um processo que será alocado na partição 3. Nesta partição os
endereços vão de 0x3000 (12288) a 0x3FFF (16383). Antes da execução do código as referências
precisam ser relocadas, desta forma o carregador irá rescrever os endereços para 0x3100
(12544=12288+256) e 0x4000 (16384=12288+4096) respectivamente.
Dentro da CPU, antes do acesso à memória, é feita a comparação entre os 4 primeiros bits do
endereço que está sendo acessado, e o conteúdo armazenado na PSW. O primeiro acesso passará
normalmente. Já o segundo gerará uma falha pois o conteúdo da PSW (3) será diferente dos 4
primeiros bits do endereço (4).
Soluções em hardware
As soluções mostradas anteriormente se baseavam na modificação das referências à memória direto
no código. Essas soluções em geral foram ruins pois tinham problemas em situações de troca do
processo e cálculo de endereços. A solução por hardware é bem menos complexa, para o
programador do sistema operacional, porém encarece o valor da CPU. Um hardware é responsável
pela validação e tradução do endereço virtual (programador) para físico (célula de memória
específica). Esse hardware é uma unidade de gerência de memória (MMU) elementar. A figura
abaixo tem um esquema de funcionamento deste hardware. O SO antes de entregar ao CPU para o
processo preenche os registradores BASE e LIMITE na MMU. Toda referência ao endereço é
comparada com o registrador limite, caso seja maior é gerada uma interrupção (falha de proteção),
se for menor é passada pelo módulo de soma e finalmente cai no barramento de endereços.
3.8 Overlays
Pela lei de Parkinson, os programadores sempre querem mais memória, neste caso mais memória
que o disponível. Em sistemas de troca de processos isso não é possível. Sendo assim uma solução
que surgiu para esse problema é o chamado Overlay (Programadores clipper/DOS vão lembrar
disto). Nesta técnica, o programador da aplicação é responsável por particionar o seu código de
forma que ele seja chamado em partes. Cada parte quando é chamada substitui a outra na memória
RAM da máquina. A solução definitiva para o problema do processo maior que a RAM é a
Memória Paginada.
3.9.1 Conceitos
Desde os primeiros sistemas de gerencia de memória não era mais dado ao programador das
aplicações a capacidade de acessar diretamente a memória física. Neste ponto surgiu o conceito de
memória virtual. Esse espaço de endereçamento manipulado pelo programador, seja por definição
de variáveis ou por alocação dinâmica, é conhecido como memória virtual.
Os dados manipulados pelo programa, são armazenados necessariamente em memória física (real),
e neste ponto é necessário que haja alguma tradução. O hardware responsável por essa tradução é a
unidade de gerência de memória ou MMU.
Para o programador o espaço de endereçamento é continuo, porém para permitir que somente partes
de um determinado programa esteja na memória, é necessário dividir o programa em fragmentos.
Esses fragmentos são conhecidos como página. A pagina pode ser virtual, correspondente ao espaço
do programador ou pode ser real, correspondente a pagina realmente ocupada na RAM, esse último
tipo de página é conhecido como moldura de página.
Em um esquema de gerência de memória por paginação existe uma estrutura que mantém o
mapeamento entre páginas e suas respectivas molduras, essa estrutura é conhecida como tabela de
páginas. Numa referencia a memória pode ocorrer duas situações: Se a página virtual estiver na
memória (se na tabela existir uma moldura equivalente) o programa executa normalmente. Caso não
haja moldura correspondente a MMU gera uma interrupção conhecida como PAGE_FAULT. E o
programa é interrompido (Bloqueado) até que página em questão (que está em disco) seja alocada
em alguma moldura.
Mapeamento
A conversão de endereços ocorre apenas nos bits mais significativos. O esquema acima mostra a
conversão com base no exemplo da figura anterior.
Ou seja com um intervalo de endereçamento de 64k e páginas de 4k termos 16 páginas virtuais (0-
15) isso interfere nos quatro bits mais significativos do endereço virtual, pois o resto dos bits (12)
são usados para acessar individualmente o dado dentro da página.
Vejamos como funciona a tradução:
Na parte de baixo do esquema o endereço virtual vindo da CPU na parte de cima o endereço
traduzido (real) que vai para o barramento de endereços.
Vamos analisar o acesso ao endereço virtual 8196 (0010000000000100)
Esse endereço está na página virtual 2 (0010). Segundo a tabela do esquema acima a pagina virtual
2 está na moldura 6 (0110) então o endereço será convertido para: (0110000000000100). O bit mais
significativo pode ser ignorado uma vez que só existem 32K (15bits) endereços reais.
Tabela de páginas
Serve para guardar, dentre outros dados, o mapeamento página virtual, real.
A cada referência à memória é feita uma tradução. Isso significa que o acesso a esta estrutura é
critico para a performance do sistema. Uma tabela de página pode ter um número grande de
páginas, por isso as técnicas de busca nesta tabela devem ser bem trabalhadas.
Em geral existem formas de armazenar essa tabela, e quanto mais rápido for a memória em que
estiver armazenada, maior vai ser a velocidade de acesso.
Implementar essa tabela em hardware, traria ganhos na velocidade de tradução, porém a quantidade
de memória necessária para esse armazenamento pode tornar o projeto caro.
A abordagem mais barata é armazenar na RAM, porém o acesso é lento. Essa é a solução usada
hoje, porém com certas modificações (mas a frente veremos como a TLB ajuda a melhorar a
velocidade).
Tabelas de Páginas Multinível
A implementação linear da tabela de páginas leva a um problema: O número de entradas pode ser
muito grande. Por exemplo: Na arquitetura Intel as páginas são de 4k e o espaço de endereçamento
é de 4G. O resultado é que uma tabela de página para um processo pode ter mais de um milhão de
entradas. Desta forma cada acesso a memória implica numa busca nestas entradas.
Um solução que surge para resolver esse problema é dividir essa busca em níveis, diminuindo assim
o escopo da busca.
Ex: Para 1M páginas é necessário 20bits. Se as páginas fossem organizadas em diretórios de 1K.
Teriamos 1K diretórios com 1K páginas.
Então para buscar um endereço seria necessário pesquisar primeiro a tabela de diretórios de páginas
“raiz” com no máximo 1k entradas, e depois pesquisar na tabela de páginas posterior, também com
1k entradas. Desta forma ao invés de buscar em 1M entradas, a busca será feita em 2k entradas.
Essa implementação de tabelas multinível pode ser feita para diversos níveis, é fácil perceber que
quanto mais níveis existir menor será o número de entradas pesquisadas, porém a complexidade do
sistema de paginação é aumentada.
O sistema operacional GNU/Linux usa 3 níveis, porém existe uma modificação (patch) para usar 4
níveis. (ref: http://lwn.net/Articles/106177/).
O MS/Windows usa dois níveis (Carece de referencias).
Formato de uma Entrada na tabela de páginas
A tabela de páginas além de possuir informações que permite o mapeamento da memória física em
virtual, também guarda outras informações necessárias para o uso do sistema operacional. São elas:
• Número da moldura: Pagina Real
• Presente/Ausente: Existe moldura equivalente? (esta na RAM)?
• Proteção: Simples (rw), Sofisticado (rwx)
• Referenciada: A pagina já foi usada?
• Modificada: A pagina foi alterada?
• Cache desabilitado: A página pode ser colocada na memória cache da(s) CPU(s).
TLB
As TLBs, também conhecidas como memória associativa, são dispositivos de hardware cujo
propósito é mapear endereços virtuais em endereços físicos sem passar pela tabela de páginas na
memória. Usualmente, ela faz parte da MMU. Ela constitui-se de um pequeno número de entradas,
muito rápidas, contendo as entradas das tabelas de páginas mais utilizadas. Quando um endereço
virtual é enviado a MMU, ela primeiramente verifica se o seu número de página virtual está
presente na TLB. Se o resultado for positivo, a moldura de página é tomada diretamente da TLB
sem a necessidade de passar pela tabela de páginas. Caso contrário, a pesquisa é feita normalmente
na tabela de páginas. Uma das entradas é removida da TLB e a entrada da tabela de páginas
pesquisada é colocada em seu lugar.
4.1 Introdução
Como vimos anteriormente os processos fazem solicitações ao hardware através do SO. Esse
hardware muitas vezes comunicam o sistema computacional ao mundo externo, representado
normalmente por um dispositivo conhecido como periférico.
Cada fabricante tem a sua forma de construir e de interfacear o periférico com o sistema de E/S. No
entanto para isso não deve afetar a forma como o processo interage como o dispositivo. Por
exemplo: O processo vai imprimir da mesma forma independente se a impressora é HP ou EPSON.
Sendo assim o principal problema do Subsistema de E/S é fornecer uma interface para que os
processos e os outros subsistemas do SO possam acessar o hardware de forma mais independente
possível.
Comunicação
Ler ou escrever em dispositivo ou ainda mandar um comando consiste basicamente em escrever em
registradores internos da sua controladora.
A escrita nestes registradores é feita através de endereços e existem duas abordagens para isso. A
primeira cria portas, que nada mais são que endereços, e para escrever nestas portas são necessárias
instruções especiais, justamente para não confundir essa escrita com a escrita em memória.
A segunda abordagem mapeia os registradores internos em endereços da memória, e para ler ou
escrever destes endereços é preciso basicamente ler ou escrever em uma posição de memória. Desta
forma não é necessários o uso de instruções especiais.
Na figura (a) temos o esquema com endereços especiais de E/S. Na figura (b) os espaços de
endereçamento são os mesmos da RAM. Na figura (c) temos um método híbrido onde o
controlador pode ser acessado tanto através de endereços de memória, como através de portas de
E/S. O Pentium usa um esquema como este último. Os endereços de 0-64k são usados como portas
de E/S e devem ser acessados através de instruções específicas (IN e OUT). Já os endereços 640K a
1M são usados para buffers relacionados a dispositivos.
Barramentos
A Figura (a) mostra a máquina de Von Neumann original previa um barramento único que iria
interligar CPU, E/S e memória. Durante muitos anos os sistemas computacionais trabalharam desta
forma.
O problema com essa abordagem é que em um barramento uma comunicação é possível por vez, e
desta forma a leitura e escrita na memória teria que concorrer com os demais dispositivos.
Na Figura (b) podemos ver um modelo onde existe um barramento exclusivo para a memória. Isso
torna o acesso à memória mais rápido uma vez que não existe concorrência.
Para ler ou escrever dados na controladora é usada a CPU, essa cópia é feita palavra por palavra,
esse tipo de abordagem acaba desperdiçar muitos ciclos de CPU, pois a CPU é sempre mais rápida
que o dispositivo. Para resolver essa questão, a ideia é usar outro dispositivo para fazer essa
transferência: O Controlador de DMA, a função dele é transferir dados entre o controlador de
dispositivos e a memória, nos dois sentidos.
O esquema de uso de DMA, pode ser distribuído, onde a controladora de dispositivo tem também
um controlador de DMA. Outro esquema, mais usado, é ter um controlador de DMA, único na placa
mãe, e este interage com os diferentes dispositivos.
O controlador de DMA é controlado através dos seus registradores internos. Um típico controlador
de DMA pode ter os seguintes registradores internos:
• Endereço de Memória: de onde ou para onde na memória
• Contador de Palavras: Quantas palavras serão transferidas
• Porta de E/S: de qual ou para qual dispositivo
• Sentido: Leitura ou escrita
4.3.1 Funcionamento
O controlador de DMA é programado pela CPU através de seus registradores internos. Então
sempre que a CPU desejar transferir dados entre memória e controlador de dispositivo através de
DMA, os seguintes eventos ocorrem:
Todo sistema computacional deve ter uma forma de armazenamento de dados que possa garantir
que a informação sobreviva ao desligamento do sistema.
Os usuários querem ter uma forma efetiva de acessar seus arquivos sem ter que se preocupar onde
os seus dados vão ficar.
Para fixar o conceito imagine que na sua empresa existe um local para armazenar os seus
documentos pessoais, e que lá existe um armário com uma divisória para cada funcionário.
Em um primeiro caso poderíamos imaginar que os próprios funcionários teriam que armazenar os
seus documentos. Neste caso, a empresa teria que contar com o bom senso de seus colaboradores
para evitar eventuais desvios (documentação misturada, extravios, etc). Tanto nas empresas como
em um sistema operacional, essa gerencia baseada no bom senso não é uma boa ideia.
Segundo caso, imagine que a empresa contratou o FS (Francisco Silva), para armazenar seus
documentos no armário, você agora só precisa entregar os seus papéis ao FS, e ele vai providenciar
o armazenamento dentro dos padrões de conformidade. Quando você precisar da sua documentação
basta pedir ao FS que ele encontra para você e entrega. Em temos de Sistemas Operacionais o FS, é
o File System ou Sistema de Arquivos, responsável por prover o armazenamento e recuperação dos
dados.
5.1 Introdução
Para que os usuários possam acessar os seus dados, a maneira que os sistemas fazem isso hoje é
fornecer duas abstrações: Arquivos e Diretórios (também chamados de pastas).
Com essas abstrações os usuários conseguem localizar os seus dados em discos com grande
números de blocos apenas informando o diretório e o nome do arquivo. Esse é o principal papel do
sistema de arquivos.
Conforme o tempo passa os discos aumentam e os arquivos também. Os bons sistemas de arquivos
devem dar a possibilidade de armazenar grandes arquivos e acessar o seu conteúdo de forma rápida
e eficiente.
Outra característica de um bom sistema de arquivos é o fato de lidar com acessos concorrentes ao
mesmo dado. Em algum momento vários processos podem acessar simultaneamente um
determinado dado, para ler ou alterar o seu conteúdo.
Nomeação
Para acessar um determinado dado armazenado em sistema, o usuário (processo) deve informar o
diretório e o nome do arquivo, a partir daí a localização do dado fica por conta do usuário.
Os diferentes sistemas operacionais tratam essa nomeação de maneira semelhante, porém com
algumas particularidades que vamos citar aqui.
Os sistemas baseado no Unix, como por exemplo o Linux, possuem um esquema de nomeação onde
a “caixa” (maiúscula ou minúscula) determina arquivos diferentes, por exemplo: Teste.txt,
TESTE.TXT e teste.TXT são arquivos diferentes. Já para o MS/Windows esses arquivos
correspondem ao mesmo conjunto de dados.
Outra característica é a extensão: Sistemas baseados em Unix não se baseiam em extensão. Ou seja
o que vem depois do '.' é uma informação que é util apenas em nível de usuário. Pois o SO não vai
tratar o arquivo de uma maneira especial tendo como base a sua extensão.
Já o MS/Windows, por exemplo, só executa arquivos com determinadas extensões (com, exe, pif,
bat, etc).
Arquivos
Os sistemas operacionais mais modernos não se preocupam com a estruturação interna dos
arquivos, a consequência disto é que, o processo do usuário tem que se preocupar com a forma que
os arquivos estão estruturados. A Figura (a) ilustra essa situação. Windows e Linux se encaixam
nesta categoria.
Diferentemente dos atuais, nos sistemas operacionais mais antigos, o SO fornece uma estruturação
elementar para o conteúdo dos arquivos. Dois exemplos são dados, Figura (b), estruturação em
registros, e Figura (c) estruturação hierárquica.
Tipos de Arquivos
Muitos sistemas operacionais classificam os arquivos conforme a sua finalidade, outros podem
classificar conforme o seu conteúdo. Porém todos os sistemas apresentam pelo menos dois tipos de
arquivo: Texto com alguma codificação específica: ASC-II ou UTF-8, ou binários, arquivos com
bytes não “imprimíveis”, que tem a sua finalidade compreendida apenas pelos programas que o
usam.