SistemasOperacionais FINAL BAIXA

Série TECNOLOGIA DA INFORMAÇÃO - hardware
Sistemas
operacionais
sistemas
operacionais
CONFEDERAÇÃO NACIONAL DA INDÚSTRIA – CNI
Robson Braga de Andrade

Presidente
DIRETORIA DE EDUCAÇÃO E TECNOLOGIA - DIRET
Rafael Esmeraldo Lucchesi Ramacciotti

Diretor de Educação e Tecnologia
SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL – SENAI
Conselho Nacional
Robson Braga de Andrade

Presidente
SENAI – Departamento Nacional
Rafael Esmeraldo Lucchesi Ramacciotti

Diretor-Geral
Gustavo Leal Sales Filho

Diretor de Operações
sistemas
operacionais
© 2012. SENAI – Departamento Nacional
© 2012. SENAI – Departamento Regional de Goiás
A reprodução total ou parcial desta publicação por quaisquer meios, seja eletrônico, mecâ-
nico, fotocópia, de gravação ou outros, somente será permitida com prévia autorização, por
escrito, do SENAI.
Esta publicação foi elaborada pela equipe do Núcleo Integrado de Educação a Distância do
SENAI de Goiás, em parceria com os Departamentos Regionais do Distrito Federal, Bahia e
Paraíba, com a coordenação do SENAI Departamento Nacional, para ser utilizada por todos
os Departamentos Regionais do SENAI nos cursos presenciais e a distância.
SENAI Departamento Nacional

Unidade de Educação Profissional e Tecnológica – UNIEP
SENAI Departamento Regional de Goiás

Núcleo Integrado de Educação a Distância – NIEaD
______________________________________________________________
S477s
SENAI-Departamento Regional de Goiás
Sistemas operacionais /SENAI – Departamento Regional de
Goiás – Goiânia, 2012.
234p.: il.
3 Conceitos de sistemas operacionais. 2.Arquitetura de sistemas

operacionais. 3.Administração de sistemas operacionais. 4.Virtualização
5. Gerenciamento e manutenção. 6. Educação a distância
I. Autor. II. Título.
CDD – 004
______________________________________________________________
SENAI Sede
Serviço Nacional de Setor Bancário Norte • Quadra 1 • Bloco C • Edifício Roberto

Aprendizagem Industrial Simonsen • 70040-903 • Brasília – DF • Tel.: (0xx61) 3317-
Departamento Nacional 9001 Fax: (0xx61) 3317-9190 • http://www.senai.br
Lista de figuras, quadros e tabelas
Figura 1 - A Arte da Guerra ...........................................................................................................................................18
Figura 2 - Administração moderna ............................................................................................................................18
Figura 3 - ISO 9001............................................................................................................................................................19
Figura 4 - Interrogação....................................................................................................................................................19
Figura 5 - Logos de sistemas operacionais..............................................................................................................20
Figura 6 - Alan Turing ......................................................................................................................................................22
Figura 7 - Von Neumann ...............................................................................................................................................23
Figura 8 - Transistor em diferentes configurações................................................................................................24
Figura 9 - Exemplo de arranjo de transistores........................................................................................................25
Figura 10 - Porta NOR com transistores ...................................................................................................................25
Figura 11 - Sistema computacional modelo...........................................................................................................27
Figura 12 - Modelo de computador...........................................................................................................................28
Figura 13 - Tempo.............................................................................................................................................................29
Figura 14 - Sistema operacional e o hardware.......................................................................................................31
Figura 15 - Esboço do mecanismo de interrupção...............................................................................................33
Figura 16 - Processador internamente .....................................................................................................................34
Figura 17 - Ambiente mainframe.............................................................................................................................. 35
Figura 18 - Desktop da Next .........................................................................................................................................37
Figura 19 - Computadores em rede ..........................................................................................................................38
Figura 20 - Sistema distribuído....................................................................................................................................38
Figura 21 - Exemplo de sistema de tempo real .....................................................................................................39
Figura 22 - Exemplo de Sistema embarcado...........................................................................................................40
Figura 23 - Fila....................................................................................................................................................................43
Figura 24 - Sala de Aula ..................................................................................................................................................45
Figura 25 - Time slice........................................................................................................................................................47
Figura 26 - Organização de sistema operacional..................................................................................................49
Figura 27 - Implementação de software...................................................................................................................51
Figura 28 - Organização de sistema operacional..................................................................................................52
Figura 29 - Kernel monolítico........................................................................................................................................53
Figura 30 - Multics ...........................................................................................................................................................54
Figura 31 - Ritchie e Thompson, dois dos desenvolvedores do Unix ............................................................55
Figura 32 - Linux ...............................................................................................................................................................62
Figura 33 - Linus Torvalds...............................................................................................................................................63
Figura 34 - Logo GNU......................................................................................................................................................64
Figura 35 - Sucesso...........................................................................................................................................................65
Figura 36 - Tendências ....................................................................................................................................................67
Figura 37 - Interpretador................................................................................................................................................73
Figura 38 - Java..................................................................................................................................................................74
Figura 39 - Java..................................................................................................................................................................75
Figura 40 - Modelo de interação Java........................................................................................................................76
Figura 41 - Sistema Operacional com virtualização e um JVM.........................................................................79
Figura 42 - Áreas de um processo...............................................................................................................................81
Figura 43 - Diagrama de estado de processo ........................................................................................................82
Figura 44 - Program Control Block (PCB)....................................................................................................................83
Figura 45 - Deadlock.........................................................................................................................................................86
Figura 46 - Memória compartilhada..........................................................................................................................89
Figura 47 - Segmentação de memória......................................................................................................................92
Figura 48 - MMU................................................................................................................................................................93
Figura 49 - Sistema de diretório em árvore.............................................................................................................97
Figura 50 - Estrutura de inodes do Unix...................................................................................................................99
Figura 51 - Network File System SUN..................................................................................................................... 101
Figura 52 - Driver de dispositivo............................................................................................................................... 103
Figura 53 - Segurança................................................................................................................................................... 109
Figura 54 - Ajuste de kernel..................................................................................................................................... 119
Figura 55 - Fdisk – executando os comandos d, 1 e p...................................................................................... 128
Figura 56 - Fdisk – disco livre, sem partições....................................................................................................... 128
Figura 57 - Fdisk – alterando o tipo de partição................................................................................................. 129
Figura 58 - Services.msc no Windows 7................................................................................................................. 131
Figura 59 - Slackware Linux /etc/inittab ............................................................................................................... 132
Figura 60 - DMESG no Linux ...................................................................................................................................... 133
Figura 61 - Saída do LSPCI e LSUB............................................................................................................................ 133
Figura 62 - Lembrete de pendências do Windows............................................................................................ 135
Figura 63 - Versões de kernel - <www.kernel.org>............................................................................................. 141
Figura 64 - Saída do tar –xvf linux-3.2.9.tar.......................................................................................................... 142
Figura 65 - Arquivos em /usr/src .............................................................................................................................. 143
Figura 66 - Link para diretório ajustado................................................................................................................. 143
Figura 67 - Aplicação de patch............................................................................................................................... 144
Figura 68 - Arquivo README...................................................................................................................................... 145
Figura 69 - Arquivo Changes................................................................................................................................... 145
Figura 70 - Versão do software................................................................................................................................ 146
Figura 71 - Versão do software................................................................................................................................ 146
Figura 72 - Funções de um sistema operacional (original do CSO_003)................................................... 148
Figura 73 - Árvore de códigos................................................................................................................................... 149
Figura 74 - Árvore de diretório de um nível......................................................................................................... 151
Figura 75 - Módulos básico de boot do Linux para a plataforma X86........................................................ 151
Figura 76 - Diretórios.................................................................................................................................................... 152
Figura 77 - Trecho de init/main.c com tentativa de execução do INIT ....................................................... 154
Figura 78 - Uso do make config................................................................................................................................ 156
Figura 79 - Uso de make menuconfig..................................................................................................................... 157
Figura 80 - Uso do make xconfig.............................................................................................................................. 157
Figura 81 - General setup kernel ................................................................................................................................ 158
Figura 82 - Item selecionado em general setup kernel...................................................................................... 159
Figura 83 - Informação da versão do kernel....................................................................................................... 159
Figura 84 - Gerar .config.............................................................................................................................................. 159
Figura 85 - Habilita o suporte a módulos no kernel......................................................................................... 160
Figura 86 - Suporte a Blocos...................................................................................................................................... 160
Figura 87 - Tratamento do PCI................................................................................................................................... 160
Figura 88 - Informação sobre o formato dos arquivos..................................................................................... 160
Figura 89 - Terminal: make menuconfig................................................................................................................ 162
Figura 90 - Tela de ajuste de processador no kernel 3.2.9................................................................................ 162
Figura 91 - Habilitando o suporte a multiprocessadores................................................................................ 162
Figura 92 - Escolha do processador......................................................................................................................... 162
Figura 93 - Processador suportado.......................................................................................................................... 163
Figura 94 - Quantidade de processadores............................................................................................................ 163
Figura 95 - Opção para habilitar 8 CPUs................................................................................................................ 164
Figura 96 - Quantidade máxima de memória física.......................................................................................... 164
Figura 97 - Virtualização de hardware ................................................................................................................... 164
Figura 98 - Escalonador preemptive....................................................................................................................... 164
Figura 99 - Gerenciamento de energia, suporte a hibernação, suporte a suspensão
de execução............................................................................................................................................... 165
Figura 100 - Listagem de dispositivos via LSPCI................................................................................................. 166
Figura 101 - Opções após Device drivers.............................................................................................................. 167
Figura 102 - Suporte a volumes lógicos................................................................................................................. 167
Figura 103 - Device drivers........................................................................................................................................ 169
Figura 104 - Trecho recortado................................................................................................................................... 169
Figura 105 - Configuração de interfaces virtuais................................................................................................ 169
Figura 106 - Habilitar protocolo PPP....................................................................................................................... 169
Figura 107 - Suporte à rede via USB........................................................................................................................ 170
Figura 108 - Suporte a rede sem fio........................................................................................................................ 170
Figura 109 - Suporte à rede........................................................................................................................................ 170
Figura 110 - Suporte a Ieee802.11........................................................................................................................... 170
Figura 111 - Suporte a bluetooth........................................................................................................................... 171
Figura 112 - Configuração de rede: opções.......................................................................................................... 171
Figura 113 - Acesso ao filtro de pacotes ............................................................................................................... 172
Figura 114 - Menu encontrado................................................................................................................................. 172
Figura 115 - Gerenciador de dispositivos.............................................................................................................. 174
Figura 116 - Trecho rc.modules ................................................................................................................................ 174
Figura 117 - Habilitar log de acesso ao I/O........................................................................................................... 175
Figura 118 - Habilitando característica.................................................................................................................. 177
Figura 119 - Suporte ao ext3...................................................................................................................................... 177
Figura 120 - Suporte a JFS.......................................................................................................................................... 177
Figura 121 - Suporte a sistema de arquivos da Microsoft............................................................................... 178
Figura 122 - Suporte a sistemas de arquivos para mídia ótica...................................................................... 178
Figura 123 - Suporte a cota de uso de disco por usuário................................................................................ 178
Figura 124 - Habilita pseudossistemas de arquivo ........................................................................................... 178
Figura 125 - Habilita suporte de sistema de arquivo em rede....................................................................... 178
Figura 126 - Suporte ao conjunto regional .......................................................................................................... 179
Figura 127 - Comando que desencadeia o processo de compilação......................................................... 180
Figura 128 - Comando para compilação dos módulos.................................................................................... 180
Figura 129 - Diretório /boot, lista de arquivos..................................................................................................... 181
Figura 130 - Comando para backup vmlinuz....................................................................................................... 181
Figura 131 - Comando para instalação do novo kernel.................................................................................. 181
Figura 132 - Comando para a instalação dos módulos compilados........................................................... 182
Figura 133 - Opção a ser escolhida no menu principal.................................................................................... 184
Figura 134 - Saída de crontab -l................................................................................................................................ 187
Figura 135 - Arquitetura do Unix em duas visões ............................................................................................. 189
Figura 136 - PATH típico no Unix/Linux.................................................................................................................. 191
Figura 137 - Script simples para saudação............................................................................................................ 193
Figura 138 - Comando para tornar arquivo em executável............................................................................ 193
Figura 139 - Linha informa que deve ser executada o sh................................................................................ 194
Figura 140 - Linha de comentário............................................................................................................................ 194
Figura 141 - Definição de variáveis e atribuição de valores............................................................................ 194
Figura 142 - Script de backup..................................................................................................................................... 195
Figura 143 - Comando Cd /......................................................................................................................................... 196
Figura 144 - Comando ls........................................................................................................................................... 196
Figura 145 - Resultado de set PATH=/etc.............................................................................................................. 196
Figura 146 - Resultado de ls.................................................................................................................................... 196
Figura 147 - Resultado encontrado......................................................................................................................... 197
Figura 148 - Inittab em CentOS 5.6 ......................................................................................................................... 198
Figura 149 - Inittab em Slackware 13.37................................................................................................................ 198
Figura 150 - Invocar o script..................................................................................................................................... 200
Figura 151 - Comando test....................................................................................................................................... 200
Figura 152 - Comando date..................................................................................................................................... 200
Figura 153 - Comando tar........................................................................................................................................ 201
Figura 154 - Comando bz2....................................................................................................................................... 201
Figura 155 - Colocando o arquivo no diretório................................................................................................... 201
Figura 156 - Script obtido............................................................................................................................................ 202
Figura 157 - Script restore.sh ..................................................................................................................................... 203
Figura 158 - Painel de controle no Windows........................................................................................................ 206
Figura 159 - Listagem de contas no Windows..................................................................................................... 207
Figura 160 - Criando uma conta no Windows..................................................................................................... 207
Figura 161 - Alerta sobre exclusão de arquivos no Windows o menu ....................................................... 208
Figura 162 - Uso do KUser para criar contas no Linux ..................................................................................... 208
Figura 163 - Criando uma conta com adduser no Linux ................................................................................. 209
Figura 164 - Apagar a conta....................................................................................................................................... 210
Figura 165 - Painel de controle por categoria..................................................................................................... 215
Figura 166 - Ferramentas administrativas no Control panel......................................................................... 216
Figura 167 - Regedit do Windows 7: tela principal............................................................................................. 217
Figura 168 - AIDA64 ..................................................................................................................................................... 218
Figura 169 - SiSoftware Sandra................................................................................................................................. 219
Figura 170 - Execução de LSPCI e LSUSB............................................................................................................... 220
Figura 171 - more /proc/cpuinfo ............................................................................................................................. 221
Figura 172 - Setagem do sistema Linux no KDE ................................................................................................ 222
Figura 173 - Webmin .................................................................................................................................................... 223
Figura 174 - Windows Update .................................................................................................................................. 225
Figura 175 - Listagem de atualizações Windows................................................................................................ 225
Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática........................15

Quadro 2 - Número de página e endereço inicial para o exemplo..................................................................93
Quadro 3 - Exemplo de uso da shell......................................................................................................................... 190
Tabela 1 - Representação em diversas linguagens de uma atribuição...........................................................70

Tabela 2 - Código em C e em Assembly.....................................................................................................................71
Sumário
1 Introdução.........................................................................................................................................................................15
2 Conceitos de sistemas operacionais........................................................................................................................17

2.1 Introdução a sistemas operacionais......................................................................................................18
2.1.1 Conceito de sistema operacional - uma visão inicial....................................................18
2.1.2 Separação de hw/sw - associação com máquina de Von Neumann.......................21
2.1.3 Funções exercidas pelo sistema operacional...................................................................27
2.1.4 Requisitos de hardware para sistemas operacionais....................................................31
2.1.5 Tipos de sistemas computacionais e sistemas operacionais......................................34
2.1.6 Histórico de sistemas operacionais: do monitor à multitarefa..................................40
2.1.7 Histórico de sistemas operacionais: sistemas de tempo
compartilhado e multiusário................................................................................................44
2.1.8 Sistema operacional - organização.....................................................................................48
2.1.9 Sistema operacional monolítico, modular e microkernel...........................................51
2.1.10 Sistema operacional multiplataforma: Unix..................................................................54
2.1.11 IBM PC e seus sistemas operacionais: do MS DOS ao Windows 7..........................58
2.1.12 Advento do Linux....................................................................................................................62
2.1.13 Estado atual...............................................................................................................................66
2.2 Virtualização...................................................................................................................................................69
2.2.1 Compilação e interpretação...................................................................................................69
2.2.2 Java virtual machine – JVM....................................................................................................74
2.2.3 Virtualização de hardware: definição e histórico............................................................76
2.2.4 Descrição de processos como virtualização....................................................................79
2.3 Arquitetura de sistemas operacionais..................................................................................................81
2.3.1 Organização de processos......................................................................................................81
2.3.2 Escalonamento e threads........................................................................................................84
2.3.3 IPC - comunicação entre processos.....................................................................................88
2.3.4 Gerenciamento de memória..................................................................................................90
2.3.5 Sistemas de armazenamento secundário.........................................................................96
2.3.6 Sistemas de arquivo em rede............................................................................................. 100
2.3.7 Entrada e saída......................................................................................................................... 102
2.3.8 Ambientes: multiprocessados, paralelo e distribuído............................................... 105
2.3.9 Segurança em sistemas operacionais............................................................................. 109
3 Administração de sistemas operacionais............................................................................................................ 115

3.1 Instalações parametrizadas de sistemas operacionais................................................................ 116
3.1.1 Impacto do sistema operacional no desempenho..................................................... 116
3.1.2 Escolhendo a versão correta do sistema operacional:
desktop, server, embarcado................................................................................................ 118
3.1.3 Escolha da versão correta do sistema operacional: 32 x 64..................................... 121
3.1.4 Escolha da versão correta do sistema operacional multicore,
multiprocessador................................................................................................................... 123
3.1.5 Ações pré-instalação: definir e executar particionamento de disco;
definir sistema de arquivo para instalação do sistema operacional,
raid, swap................................................................................................................................ 126
3.1.6 Ações pós-instalação para otimização de driver, remoção de serviço................ 130
3.1.7 Ativação de serviços ............................................................................................................. 134
3.2 Compilação de kernel............................................................................................................................... 137
3.2.1 Ajustes e versões do kernel ................................................................................................ 137
3.2.2 Baixando o kernel e o patch................................................................................................ 140
3.2.3 Ambiente de compilação e ajustes.................................................................................. 144
3.2.4 Organização do kernel – parte 1........................................................................................ 147
3.2.5 Organização do kernel – parte 2....................................................................................... 152
3.2.6 Parametrizando aspectos gerais, versão e .Config..................................................... 156
3.2.7 Parametrizando processador e smp................................................................................ 161
3.2.8 Parametrizando device bloco pata/sata/scsi................................................................ 165
3.2.9 Parametrizando device de rede......................................................................................... 168
3.2.10 Parametrizando filtragem de pacotes/netfilter......................................................... 172
3.2.11 Parametrizando device drivers........................................................................................ 173
3.2.12 Parametrizando segurança............................................................................................... 175
3.2.13 Parametrizando sistemas de arquivos.......................................................................... 176
3.2.14 Compilação e instalação do novo kernel..................................................................... 179
3.2.15 Recuperando-se de uma falha......................................................................................... 182
3.3. Automação de tarefas utilizando-se de scripts.............................................................................. 184
3.3.1 Uso de scripts........................................................................................................................... 184
3.4 Ambientes shell.......................................................................................................................................... 188
3.4.1 Shell e variáveis de ambiente............................................................................................. 188
3.4.2 Shell scripts............................................................................................................................... 192
3.4.3 Shell scripts – preexistentes................................................................................................ 197
3.4.4 Shell scripts – desenvolver.................................................................................................. 199
3.5 Contas e perfis de usuários localmente............................................................................................ 204
3.5.1 Política de senhas................................................................................................................... 204
3.5.2 Criação e remoção de contas locais................................................................................. 204
3.5.3 Proteção de arquivos via acl............................................................................................... 210
3.6 Gerenciamento e manutenção............................................................................................................ 212
3.6.1 Planejamento de manutenção e gerência em sistema operacional e
ferramentas para auxílio no gerenciamento................................................................ 212
3.7 Ferramentas e acessórios de sistemas visando às funções de configuração...................... 215
3.7.1 Ferramentas para administração Windows 7................................................................ 215
3.7.2 Ferramentas para administração Linux........................................................................... 219
3.8 Gereciamento e manutenção............................................................................................................... 223
3.8.1 Upgrade e manutenção no ambiente Windows 7 e Linux...................................... 223
Minicurrículo do autor................................................................................................................................................... 229
Índice................................................................................................................................................................................... 231
Introdução
Caro aluno, nesta unidade você entenderá qual a responsabilidade do sistema operacional
em gerenciar recursos de hardware, como o tipo de processador, a quantidade de memória, o
disco rígido e a placa de vídeo.
Nesta unidade você também aprenderá mais sobre as funções, requisitos e arquitetura de
sistemas operacionais, bem como os tipos existentes.
A seguir, são descritos na matriz curricular os módulos e as unidades curriculares do curso,
assim como suas cargas horárias.
Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática
CARGA CARGA HORÁRIA

MÓDULOS UNIDADES CURRICULARES
HORÁRIA DO MÓDULO
• Fundamentos para Documentação Técnica 140h
Básico • Eletroeletrônica Aplicada 120h 320h
• Terminologia de Hardware, Software e Redes 60h
• Arquitetura e Montagem de Computadores 160h
• Instalação e Manutenção de Computadores 250h
• Instalação e Configuração de Rede 160h
• Segurança de Dados 50h
Específico I 880h
• Sistemas Operacionais 120h
• Gerenciamento de Serviços de TI 80h

• Tendências e Demandas Tecnológicas em TI 60h
Bons estudos!
Conceitos de sistemas operacionais
A gestão dos recursos de hardware cabe ao sistema operacional. O tipo de processador, a

quantidade de memória, o disco rígido, a placa de vídeo, são recursos que necessitam ser ge-
renciados.
Veremos, neste capítulo, que existe a necessidade de gerência de recursos de forma adequa-
da, e o sistema operacional possui esta reponsabilidade.
Após o estudo deste capítulo você poderá ser capaz de definir:
a) o impacto do sistema operacional no desempenho;
b) definir a escolha da versão correta de sistemas operacionais;
c) definir ações de pré-instalação;
d) definir ações pós instalação para otimização de driver e remoção de serviços;
e) compreender a ativação de serviços;
f) compreender os procedimentos para a compilação de Kernel;
g) conhecer a aplicar ambientes Shell e Automação de Tarefas utilizando-se de Scripts;
h) conhecer e proceder na criação de Contas e Perfis de Usuários Localmente;
i) conhecer o Gerenciamento e manutenção;
j) conhecer as ferramentas e acessórios de sistemas visando às funções de configuração
O computador está presente para ajudar na solução de problemas e não ser um novo pro-
blema. Assim como profissional de TI é importante que você entenda também a metodologia
de operação destes sistemas e seus gerenciamentos.
Sistemas Operacionais
18
2.1 INTRODUÇÃO A SISTEMAS OPERACIONAIS

1 ISO
Organização Internacional
de Padronização. 2.1.1 CONCEITO DE SISTEMA OPERACIONAL - UMA VISÃO INICIAL
Você já se perguntou de que forma elaboramos um planejamento? Como

definimos as estratégias? Como gerenciamos uma empresa ou cuidamos de um
computador?
Voltemos no tempo! China, século IV antes de Cristo. Na obra “A arte da guerra”
(TZU, 2008), Sun Tzu, um general, traça estratégias para vencer uma guerra. Ele des-
creve de forma organizada as ações e as funções relacionadas à arte militar e, dessa
forma, instruiu os leitores sobre como administrar recursos para uma guerra.
Dreamstime (2012)
Figura 1 - A Arte da Guerra
Retornemos ao século XX, após a revolução industrial, na revolução elétrica.

A teoria geral de administração moderna, ensinada nos cursos de Administração
de Empresas e Engenharia de Produção, focou em como administrar os recursos
de uma empresa para que atingisse sucesso no mercado. Instrui a administrar
recursos para o sucesso empresarial.
Dreamstime (2012)
Figura 2 - Administração moderna

2 Conceitos de sistemas operacionais
19
A famosa norma ISO19001, almejada por tantas empresas, ensina às institui-

ções como ter qualidade total no processo produtivo. Apresenta um foco inte-
ressante, pois é organizada em procedimentos gerais e específicos exigindo o
desenvolvimento de produtos sempre dentro de padrões esperados, ressaltando
a satisfação dos clientes. Instrui as empresas a como obter sucesso por meio de
métodos bem estabelecidos.
Denis Pacher (2012)

Figura 3 - ISO 9001
Denis Pacher (2012)
Figura 4 - Interrogação
Neste momento, você deve estar pensando qual a relação entre a guerra, a ad-
ministração moderna e o processo fabril, não é mesmo? O que existe em comum
nas três?
Uma resposta possível seria a presença de um sistema que gerencia o conjun-
to de operações de cada uma das atividades citadas acima, gerencia o conjunto
de metas. No primeiro caso, um sistema operacional para a guerra; no segundo,
um sistema para gestão e, no terceiro, um sistema para o processo fabril.
20
E o computador, quando entra nesse processo? Chegaremos lá! Mas antes, re-
finaremos mais um pouco a definição de sistema operacional.
Em que consiste um sistema operacional?

Sistema é um conjunto de elementos autônomos que ope-
rados em conjunto chegam a um determinado resultado.
SAIBA
Podemos dizer que um sistema operacional consiste em
MAIS um conjunto de regras e funções bem estabelecidas, forma-
lizadas e empregadas para se obter um resultado em uma
determinada área. São as regras de como se trabalha e se faz
algo, deixando clara a função de cada um.
SISTEMAS OPERACIONAIS COMPUTACIONAIS
Denis Pacher (2012)

Figura 5 - Logos de sistemas operacionais
Os primeiros computadores consistiam basicamente em estruturas de combi-

nações eletroeletrônicas. Operá-los significava manipular seus painéis e modificar
sua “programação” para permitir a execução de diversos programas.
Com a evolução do hardware, a partir do uso de programas armazenados em
dispositivos de armazenamento secundário (fitas), surge a figura do operador de
sistema. Esse operador tinha como função montar (colocar) a fita com os progra-
mas em sua unidade, para que esta fosse lida pelo computador.
O operador era responsável por montar a fita e, no terminal de controle (con-
sole), fazer a execução de comandos que permitiam ao programa ser carregado
a partir dela para a memória principal. De acordo com o conceito de máquina
de Von Neumman, os programas deviam estar na memória principal para serem
executados. Somente algum tempo depois de serem executados manualmente,
notou-se que essa tarefa repetitiva podia ser automatizada por um software que
foi denominado programa monitor.
Com a integração de novas funções ao hardware e aumento de sua complexi-
dade, o programa monitor foi sendo gradativamente incorporado, de forma que
21
permitisse a operação do sistema computacional. O programa monitor não é so-

mente de carga de software, mas um sistema que gerencia a operação do compu-
tador: um sistema operacional.
Os sistemas operacionais computacionais, da mesma forma que nos fatos ci-
tados na introdução, são elementos que permitem a plena funcionalidade do sis-
tema computacional.
Notavelmente, uma segunda função dos sistemas operacionais é o forneci-
mento de uma abstração de serviço e de conceitos – faz o papel de intermediário
entre os aplicativos e o hardware. Com o hardware computacional cada vez mais
complexo e diverso (cada fornecedor tinha características únicas em seus proje-
tos), optou-se por incorporar ao sistema operacional a função de esconder suas
características específicas, bem como fornecer a visão de conceitos que só exis-
tem no mundo real. Como exemplo, temos o sistema de arquivos, que permitem
um acesso amigável aos blocos de disco, fitas e CDs.
Agora que você já viu o que é um sistema operacional computacional, vamos
retornar ao início do texto. Você notou a semelhança entre a visão de Sun Tzu (ne-
cessidade de se ter métodos claros para a gestão) e as possibilidades e necessida-
des que surgem com a evolução da informática? O importante é perceber que com
o estabelecimento de um sistema de gestão no ambiente de computação, temos
como consequência o uso dos sistemas operacionais de forma adequada e eficaz.
Continue atento e vamos em frente!
2.1.2 SEPARAÇÃO DE HW/SW - ASSOCIAÇÃO COM MÁQUINA DE VON

NEUMANN
Na área de computação, temos o hábito de, algumas vezes, estudar algum

tema sem entender sua origem ou razão de ser. Para que isso não ocorra no seu
processo de estudos, neste tópico, você encontrará um pouco da história da com-
putação. Você vai aprender a diferenciar o que é hardware e software, além de
entender melhor o papel do sistema operacional. Vamos em frente!
22
O HARDWARE E O SOFTWARE
Dreamstime (2012)
Figura 6 - Alan Turing
Vamos retornar à década de 20, quando o matemático Alan Turing definiu o

que seriam os computadores atuais e como seria o seu funcionamento. Surge aí o
conceito de autômato finito, uma máquina abstrata, não real, baseada nos precei-
tos matemáticos de Teoria dos Grafos, que essencialmente consistia em uma fita
com comandos sequenciais que alguém poderia ler e executar. A partir daí, esta-
va criado o conceito de máquina sequencial e de estado de execução. Parece uma
criação simples, não é? Mas é importante ter em mente que tudo começa aqui!
Alan Turing (1912 a 1954) em 1975 foi considerado o

VOCÊ pai da informática, por suas contribuições na criação do
conceito de autômato finito. Você pode saber um pouco
SABIA? mais sobre Alan Turing acessando o site: <http://www.
turing.org.uk/turing/>.
SAIBA Leia mais informações sobre a Teoria dos Grafos em <http://

MAIS www.inf.ufsc.br/grafos/>.
23
Dreamstime (2012)
Figura 7 - Von Neumann
Viajando para a década de 50, constataríamos que o computador eletrônico

já existia, além de observar Von Neumann conceituar máquina com programa
em memória principal (o programa a ser executado deveria ser colocado em me-
mória antes de sua execução). O sistema operacional surge como um elo entre
humanos e os diferentes hardwares de diferentes fornecedores. Nesse momento,
você pode estar se perguntando: e da década de 20 à década de 50, o que aconte-
ceu? E no que consiste esse tal de hardware, software e sistema operacional? Para
que tudo fique mais claro, vamos visitar o período entre as décadas de 20 e 50,
para conhecer as bases do “admirável mundo novo” da informática.
Os primeiros computadores eletrônicos construídos eram formados de arran-
jos eletromecânicos (chaves, válvulas) e eletrônicos (relés), que podiam ser con-
figurados fisicamente por técnicos especializados a cada nova execução de uma
atividade, ou seja, mudando as chaves e ajustando o circuito elétrico. O computa-
dor era “transformado” a cada nova execução de tarefa.
Dada a existência do equipamento, especialistas modelavam o problema em
um circuito combinacional e definiam o que deveria ser alterado nesse equipa-
mento, mudando/ajustando o hardware (a máquina). A seguir, a máquina era li-
gada e era necessário esperar o final do processamento (executar a atividade). Por
fim, são pegos os valores de saída e a tarefa está terminada.
E para executar outro problema, você sabe o que precisava ser feito? O har-
dware deveria ser alterado novamente.
Com isso, podemos notar que era uma tarefa repetitiva, rotineira, cara e pas-
sível de erros.
Contudo, mesmo nequela época, já podemos notar claramente a separação
de hardware (o equipamento a ser mexido, manipulado) e de software (o conjun-
24
to de ações que esse hardware iria executar). Um hardware era capaz de executar
diferentes softwares, desde que devidamente ajustado. Podemos dizer que o pro-
jeto de software da época consistia em projeto mecânico e elétrico.
O uso de relés simplificou o equipamento (computador), mas somente com o
surgimento dos transistores baseados em semicondutores conseguimos progra-
mar de forma adequada os preceitos de portas lógicas, e seguir o trabalho usando
lógica matemática.
O TRANSISTOR: A PORTA LÓGICA
O transistor permitiu a flexibilidade, por meio de semicondutores, de se confi-

gurar as funções de todo um computador sem ter que mexer na máquina fisica-
mente – apenas enviando comandos. Vamos recapitular esse conceito eletrônico
devido a sua importância na separação de hardware e software.
Um transistor visto em diversos formatos, na figura abaixo, possui três
conectores:
a) Coletor (C): onde colocamos a eletricidade;
b) Emissor (E): por onde sai a eletricidade;
c) Base (B): controla a saída ou não da eletricidade. Denis Pacher (2012)
Figura 8 - Transistor em diferentes configurações
Podemos pensar no transistor como uma porta elétrica. Colocamos eletrici-

dade no coletor e, se tivermos presença de eletricidade no terminal de base, o
transistor deixa a eletricidade passar para o terminal emissor.
25
Interessante, não é mesmo? Mas provavelmente você vai se perguntar: o que

isso tem a ver com informática? Se pensarmos em um transistor sozinho, nada.
Mas se pensarmos em ligar o emissor de um transistor na base de outro, como na
figura abaixo?
+VS
Transistor
Vin VE
RLoad
Denis Pacher (2012)

-VS
Figura 9 - Exemplo de arranjo de transistores
O transistor 2 (dois) vai deixar passar eletricidade apenas se o 1 (um) estiver

passando eletricidade. Na verdade existem dois tipos de transistores, um que dei-
xa passar eletricidade se tiver corrente na base e outro que possui comportamen-
to complementar, passa eletricidade se não tiver corrente em sua base.
Se colocarmos milhões desses transistores em um circuito que combina essas
facilidades, temos um circuito combinacional. Dependendo da eletricidade que co-
locamos na entrada desse circuito, esse hardware será levado a apresentar compor-
tamentos diferentes. A figura abaixo mostra um arranjo de uma porta lógica NOR:
+Vcc
B A OUT
0 0 1
0 1 0 R2
1 0 0
1 1 0 OUT
T1 Q = A+B
R
A
Transistor
Switches
R
B
Denis Pacher (2012)
T2
Figura 10 - Porta NOR com transistores

26
Vamos utilizar os valores da lógica matemática como verdadeiro e falso (0 e 1)

– podemos pensar o 1 como presença de eletricidade e o 0 como ausência. Logo,
baseando-se nos valores de entrada do sistema, temos comportamentos diferen-
tes no circuito combinacional que consiste nosso computador. Surge o compu-
tador moderno, digital e programável. Um artefato eletrônico que, acessando-o
por meio de suas interfaces de entradas, realiza funções específicas, não sendo
necessário mexer fisicamente no hardware. Basta programá-lo com números: são
os sistemas programáveis.
INTRODUÇÃO A SISTEMAS OPERACIONAIS
Este advento citado nos parágrafos anteriores nos leva à separação do har-
dware e do software. O hardware é o circuito combinacional eletrônico. O software
é o conjunto de números, 0 e 1. São instruções apresentadas ao hardware, como
se escritas em uma fita de dados, criando um autômato finito eletrônico.
O SISTEMA OPERACIONAL
Ao longo da década de 40, com possibilidade de “transformar” o computador

por meio de instruções de software do programa, sem a intervenção humana nos
circuitos, surgiu a ideia de um pequeno programa: monitor. Este ficaria na me-
mória do computador e seria responsável por colocar os programas do usuário
para executar, gerenciando os periféricos envolvidos.
Nessa época, o hardware era muito simples, mas o modelo básico de proces-
samento continua o atual:
a) programas e dados são fornecidos por periféricos (canais) de entrada e o
resultado apresentado na saída;
b) por conceito (Von Neumann), os programas são colocados antes na memó-
ria principal, que serve como área de trabalho;
c) o processamento se desenvolve na CPU;
d) arquivos (em dispositivos de entrada e saída, como armazenamento perma-
nente fita, disco rígido e SD, como exemplos) podem ser usados para guar-
dar dados que serão usados no futuro, bem como armazenar os programas
antes de executar.
Temos, então, a figura abaixo que simboliza nosso computador:
27
Memória
entrada Saída
Processamento
Denis Pacher (2012)

Arquivos
Figura 11 - Sistema computacional modelo

Fonte: Autor
Você verá que, ao longo do curso, nosso foco será trabalhar com os sis-
temas operacionais levando em conta o modelo acima e a gerência de suas
diversas partes.
Após conhecer um pouco da história da computação, você aprendeu sobre a
separação do que é hardware e do que é software. Assim, compreendeu melhor o
papel do sistema operacional.
Você teve a oportunidade de acompanhar a evolução dos computadores ele-
trônicos e o ponto crucial em que surge a separação do hardware (o físico) e do
software (a parte lógica). Também viu a relação disso com o uso de transistores e
o surgimento dos sistemas operacionais. Ao olhar para um circuito eletrônico ou
para um código fonte, talvez a visão seja diferente a partir de agora. Faça a ativi-
dade abaixo e vamos em frente!
2.1.3 FUNÇÕES EXERCIDAS PELO SISTEMA OPERACIONAL
Você já se perguntou como o computador pode executar vários programas ao

mesmo tempo com um processador? Já pensou em como essa máquina não se
confunde? Descreveremos, neste tópico, o responsável por esses feitos: o sistema
operacional.
Começaremos com a pergunta clássica: o que faz um sistema operacional?
O sistema operacional é constituído por um conjunto de programas que ge-
rencia o hardware, fornecendo serviços padronizados aos seus usuários. Gerencia
28
também as partes do hardware, garantindo melhor uso das aplicações dos usuá-
2 FORTRAN rios. Outro objetivo é o histórico: portabilidade de aplicações.
É a primeira linguagem Na década de 50, cada fabricante de hardware tinha componentes únicos,
de alto nível lançada no
mercado. cada um desenvolvia seus periféricos de entrada e saída, organização de memó-
ria, CPU e linguagem de programação de baixo nível (linguagem de máquina).
Nesse contexto, em que cada componente realizava tarefas de modos diferen-
3 MIDDLEWARE tes, os sistemas operacionais tinham como objetivo isolar este mundo, digamos
hostil, do usuário final (programador de software). A ideia era que o usuário tives-
É um programa de
computador que faz a se sempre a visão de um mesmo hardware, sem se preocupar com detalhes de
mediação entre software e
as demais aplicações. implementação. Essa visão foi acentuada com a criação da linguagem Fortran2,
que permitiu o desenvolvimento de softwares independentes dos hardwares, por
ser uma linguagem de alto nível.
Os sistemas operacionais consistiam, talvez, na primeira versão do que cha-
mamos de middleware3 (ou mediador), uma camada entre dois mundos que faz a
mediação entre software e demais aplicações, isolando e provendo serviços uni-
formes entre eles. Outros exemplos de mediadores seriam os SAPs (Service Access
Point), visto em redes de computadores, e a JVM (Java Virtual Machine).
Vamos analisar agora a figura abaixo para descrevermos as funções de um sis-
tema operacional.
Memória
entrada Saída
Processamento
Denis Pacher (2012)
Arquivos
Figura 12 - Modelo de computador
Os componentes básicos desta figura você já conhece, não é mesmo? Então,

qual a importância dessa imagem?
29
Depois de um longo período da construção do hardware computacional, os

cientistas da computação conseguiram torná-lo programável por software. Te-
mos a CPU, que realiza o processamento, mas para realizá-lo, precisamos pegar o
programa de algum lugar e entregá-lo à CPU para execução. Nos primeiros har-
dwares, este lugar era apenas um deck (fila) de cartões perfurados que continham
o programa do usuário. O programa era colocado no deck e, logo depois, era a vez
dos dados serem inseridos lá. O monitor (versão simplificada do sistema opera-
cional), operado por uma pessoa, “carregava” (load) os dados dos cartões para a
memória do computador, permitindo sua execução. Com o término da execução,
o mesmo monitor coordenava o envio dos dados para a unidade de saída, nor-
malmente uma impressora, e lia a nova fila de cartões no deck de entrada, dando
início a um novo ciclo de processamento. Por esse modelo, diversos programas
podem ser executados, mas um de cada vez.
A NECESSIDADE DE GERÊNCIA DO HARDWARE
Suponha que a aplicação que desejamos executar é um sistema de folhas de

pagamento que calcula o salário a ser pago no final do mês, emitindo um relatório.
A empresa que utilizará este sistema tem dez mil funcionários. O processa-
mento da folha de pagamento nas máquinas da década de 50, para esta quanti-
dade de dados, levaria talvez alguns minutos, mas imagine agora o relatório de
saída impresso. Dez mil funcionários significam pelo menos dez mil linhas impres-
sas. Quanto tempo isso levaria?
Denis Pacher (2012)
Figura 13 - Tempo
Digamos que uma impressora da época tivesse capacidade de imprimir 20 ca-

racteres por segundo. Se cada linha tivesse 132 caracteres, teríamos a capacidade
de imprimir duas linhas por minuto, então gastaríamos cinco mil minutos para
imprimir o relatório, ou seja, algo perto de 80 horas de atividade de impressão.
30
Durante esse tempo de I/O (entrada e saída) a CPU ficava parada, deixando o pe-
riférico (impressora) funcionar.
Uma questão que surgiu foi: se temos uma CPU que custou uma fortuna, como
deixá-la parada na maior parte do tempo, esperando a entrada dos dados para a
memória ou a saída de um relatório? O que fazer?
Essas questões levaram ao avanço no desenvolvimento dos sistemas opera-
cionais. O objetivo era permitir explorar o uso da CPU do computador, de forma
que os seus recursos fossem melhores aproveitados.
A resposta veio com o conceito de sistema multitarefa, que permitiu a um
programa em execução efetuar outra tarefa enquanto estivesse esperando uma
atividade de entrada e saída (como a listada no exemplo). Quando a nova tarefa
terminasse ou entrasse em I/O, a tarefa antiga poderia ser retomada. Dessa forma,
temos um sistema multitask ou multitarefa.
Com esses sistemas, o avanço em sistemas operacionais foi interessante, de-
vido à necessidade de implementar mecanismos de proteção às aplicações em
execução. A ideia era que uma não interferisse na outra, garantindo que os dados
que estavam no processador fossem salvos em algum lugar quando uma tarefa
fosse retirada da execução e encaminhada para uma atividade de I/O.
Os conceitos básicos e os módulos que compõem um sistema operacional
neste contexto são:
a) Gerente de I/O: cuidava dos diversos periféricos;
b) Gerente de memória: garantia o uso adequado e proteção das diversas ta-
refas executadas, por meio da gerência e da proteção de memória;
c) Gerente de arquivos: servia como um agrupador de arquivos, permitindo
gerenciar os dados armazenados nos I/O ou no disco rígido. Para entender
melhor o gerente de arquivos e para que as informações ficassem organiza-
das corretamente, eram utilizados termos comuns: armários (diretórios), que
possuem pastas (arquivos), que possuem registros;
d) Gerente da CPU: trocava as diversas tarefas em execução, iniciando e ter-
minando-as. A denominação dessa funcionalidade do módulo do sistema
operacional foi Gerente de processos. Já o ato de trocar processos em exe-
cução foi denominado de escalonamento.
O escalonamento de processos tem um incremento na sua complexidade
quando passamos a trabalhar com terminais conectados aos computadores no
lugar do deck de cartões, permitindo que diversos usuários acessem o computa-
dor ao mesmo tempo. Surge os chamados sistemas de tempo compartilhado, em
que a CPU tem seu tempo de uso dividido entre diversos usuários, minimizando
o tempo parada.
31
Podemos, então, ajustar a figura anterior para a figura abaixo, em que sobre-
pomos as funções do sistema operacional ao hardware, permitindo-nos entender
o papel de cada parte (gerente) do sistema operacional no processo de gestão.
Gerente de
memória
Memória
Gerente de
processos
Gerente entrada Saída Gerente

de I/O de I/O
Processamento
Arquivos
Denis Pacher (2012)

Gerente de
arquivos
Figura 14 - Sistema operacional e o hardware
Ressaltamos que as linhas pontilhadas ligam arquivos à entrada e saída. Com o

uso do armazenamento de dados em sistemas de arquivos, eles são usados para
alimentar o sistema na entrada e guardar os dados na saída.
E então, você conseguiu entender como o computador faz para executar di-
versas tarefas ao mesmo tempo? Agora, quando você ligar o computador e ver
diversas tarefas em execução, lembrará que isso só é possível devido à presença
do sistema operacional, que em seus diversos módulos, possibilita a execução de
múltiplas tarefas sobre o mesmo hardware. Também deve ter compreendido a
importância da necessidade do gerenciamento do hardware de forma adequada
e organizada, não é mesmo?
Então vamos em frente. Nosso próximo passo é conhecer alguns requisitos
necessários para que o hardware funcione de forma adequada.
2.1.4 REQUISITOS DE HARDWARE PARA SISTEMAS OPERACIONAIS
Você já percebeu que para muitas coisas que desejamos fazer, temos alguns re-
quisitos para cumprir antes de seguir em frente? Na escola, por exemplo, precisa-
mos passar em todas as disciplinas de uma série para avançarmos para a próxima.
32
E no computador, existem requisitos ou exigências para que o hardware fun-

4 Polling cione de forma adequada? Sim, existem vários requisitos! Vamos discutir cada um
Consulta.
deles neste tópico.
Um SO (Sistema Operacional) apresenta uma face padronizada de acesso ao
hardware e, por isso, é necessário conhecer o hardware onde o SO será desenvol-
5 Escalonamento vido e implantado. Certos aspectos da organização do hardware, bem como suas
características e opções de execução, têm sido padronizados ao longo do tempo.
Agendador de tarefas.
Como pressuposto para o nosso trabalho com sistemas operacionais, alguns as-
pectos serão levados em conta, especialmente o tratamento de eventos, relógio
de tempo real e gerência de memória.
INTERRUPÇÃO
Em um computador atual, um processador está conectado a um conjunto de

periféricos, além de ser o responsável pela gerência desse conjunto. A partir dessa
informação, uma questão que surge é: como um periférico pode solicitar atenção
da CPU? Existem duas abordagens principais: interrupção e polling4.
No mecanismo de polling, a CPU, empregando um algoritmo de lista circu-
lar, por exemplo, pergunta a cada um dos periféricos se desejam atenção. Se um
deles desejar, será atendido. Essa abordagem é pouco empregada atualmente,
devido ao custo computacional envolvido, e não será estudada.
No mecanismo de interrupção, existe um pino denominado INTR que fica lo-
calizado na CPU. Quando um periférico solicita atenção, esse pino gera um si-
nal elétrico e a CPU interrompe o que estava fazendo para atender à solicitação
do periférico.
Para permitir o tratamento de mais de um periférico, já que existe apenas um
pino INTR na CPU, a solução é ligar a saída de um microcontrolador especializado
no tratamento de interrupções à CPU, por meio do pino INTR. Nesse microcon-
trolador, denominado de controlador de interrupções, são ligados os pinos dos
periféricos. Assim, temos um mecanismo de multiplexador que permite várias en-
tradas e uma saída. Podemos visualizar este arranjo na figura abaixo.
33
Barramento
CPU
dados
Con
br
IRQ
Denis Pacher (2012)

Barramento
endereço
Figura 15 - Esboço do mecanismo de interrupção
Explicaremos, então, o uso do mecanismo de interrrupção:

O periférico solicita atenção ao controlador de interrupções, Programmable in-
terrupt Controller (PIC), via pino do PIC. Esses pinos do PIC são numerados e o nú-
mero indica a interrupção. O PIC informa à CPU a solicitação feita pelo periférico
e a CPU atenderá à demanda do periférico via barramento de dados e endereço.
Esse mecanismo de interrupção da atividade da CPU para a atenção a um peri-
férico será essencial em uma série de funções do sistema operacional, em especial
na gerência de processos e no escalonamento5 em sistema com suporte a vários
usuários e tarefas (neste caso, aliado ao relógio de tempo real).
RELÓGIO DE TEMPO REAL
O relógio de tempo real, baseado em um cristal de quartzo, é responsável por

manter a hora do sistema ativa. Isso é de suma importância para permitir que
sejam estabelecidos tempos de execução para cada processo/programa que está
executando, quando trabalharmos com sistemas de tempo compartilhado.
34
GERÊNCIA DE MEMÓRIA
Nahalem Glamour Shot (2012)

Figura 16 - Processador internamente
A memória principal do computador é essencial para o bom desempenho do

sistema como um todo. O gerenciamento de memória (Memory Management Unit
– MMU) está a cargo do módulo de gerência de memória da CPU, que programa
os padrões de segmentação de memória, essencial para o bom desenvolvimento
de programas e paginação de memória. Também é fundamental para o melhor
uso da memória e para permitir a proteção e isolamento de diversos processos
em execução.
O processo de paginação é essencial por garantir a pro-

VOCÊ teção do sistema operacional. Se um processador não
suportar adequadamente a paginação, dificilmente con-
SABIA? seguiremos desenvolver um sistema operacional multi-
tarefa/multiusuário estável para esse processador.
Você conheceu e compreendeu quais os diversos componentes do hardware

que são essenciais para um sistema operacional ser implementado e funcionar de
forma adequada.
Está pronto para partir para o próximo passo? Vamos em frente!
2.1.5 TIPOS DE SISTEMAS COMPUTACIONAIS E SISTEMAS

OPERACIONAIS
A computação é marcada por diversas mudanças, desde a forma como as pes-

soas usam os computadores até a forma como essas máquinas são configuradas.
35
Desde a criação do primeiro computador até a atualidade, essa ferramenta vem

ganhando potência, agilidade, dentre outras características.
O sistema computacional é um conjunto de dispositivos eletrônicos capazes
de processar informações por meio do uso de softwares. Já o sistema operacional
é a plataforma onde todos os outros softwares serão instalados. É ele quem deixa
o computador utilizável, pois proporciona suporte para todos os outros progra-
mas funcionarem, oferecendo as bases para a execução das aplicações desenha-
das pelos usuários.
Você já fez uma visita a um clube? Sim, então percebeu que existem diversos
tipos de quadras e campos para a prática das diferentes modalidades esportivas:
futebol, futebol de salão, vôlei, basquete, dentre outras. Todos são esportes pra-
ticados em quadra ou campo, mas cada um tem sua especificidade. Imagine se
houvesse só um juiz para apitar nestas diferentes modalidades esportivas. Seria o
ideal? A probabilidade desses juízes não julgarem a partida de forma correta seria
maior, pois eles conheceriam todas as modalidades, mas não seriam especialistas
em nenhuma delas.
Considere agora se os computadores que realizam diversas tarefas, desde um
simples editor de texto, um servidor na internet ou a automação de uma usina
nuclear, usassem o mesmo tipo de sistema operacional. Não seria a solução ideal,
não é mesmo? Para identificarmos essas diferenças e quais sistemas operacionais
são adequados às diferentes situações, conheceremos os tipos de sistemas com-
putacionais e operacionais disponíveis no mercado.
TIPOS DE SISTEMAS COMPUTACIONAIS E SISTEMAS OPERACIONAIS
a) MAINFRAME
FabriCO (2012)
Figura 17 - Ambiente mainframe

36
O mainframe tem como característica principal a presença do hardware com-

putacional organizado em:
a) Unidade Central de Processamento (CPU): é o módulo principal responsável
pelo processamento, em que também fica instalada a memória principal;
b) Controladora de disco: local em que estão conectados os discos de dados;
c) Controladora de fita: local em que as unidades de fita estão conectadas;
d) Controladora de comunicação: onde estão conectados os terminais dos
usuários;
e) Canal de comunicação rápido: permite a conexão entre as controladoras e
a CPU.
O modelo mainframe foi a tecnologia soberana no mercado computacional
até o final da década de 70, quando surgiram os primeiros computadores pesso-
ais. Ao longo desta década foram desenvolvidos os primeiros sistemas de médio
porte, como os minicomputadores, que eram mainframes em pequena escala,
com uma série de controladoras na mesma caixa (gabinete).
Como característica principal desse modelo, temos o processamento centrali-
zado em apenas uma CPU, com acesso por diversos terminais de entrada e saída
(terminais de texto e impressoras), por onde os usuários faziam uso do sistema. O
sistema operacional tem aqui a característica principal de suporte a multiusuário
(vários usuários) e multitarefa (várias aplicações executando ao mesmo tempo),
bem como o suporte ao que se convencionou na época chamar de teleinformáti-
ca, que é o acesso remoto ao mainframe por meio de rede de dados conectado a
controladora de comunicação.
Nestes sistemas de médio porte, problemas de compartilhamento de arqui-
vos, backups e suporte a mudanças no hardware e softwares foram minimizados,
pois todos os recursos estavam centralizados em único local e eram gerenciados
por profissional específico – o operador.
Você sabia que os chamados mainframes praticamente

VOCÊ foram extintos do mercado e só voltaram a ter populari-
SABIA? dade com a possibilidade de receberem a instalação do
sistema operacional Linux?
37
b) DESKTOP
NeXT Inc. (2012)

Figura 18 - Desktop da Next
Fonte: http://cdn.dipity.com/uploads/events/54a013bc0bef0da86d6baee81e2ede7a_1M.png
A década de 80 foi marcada pela consolidação dos computadores de uso pes-

soal, os microcomputadores, que surgiram no final da década anterior. As primei-
ras características da microinformática são:
a) all-in-one (tudo em um): todos os componentes (CPU, memória, periféricos
de entrada e saída, disco de dados etc) ficavam alocados em uma mesma
“caixa”;
b) cada usuário era responsável por sua máquina: não existia administração
centralizada;
c) não existiam repositórios de arquivos: ficavam guardados localmente e po-
diam ser copiados e movidos entre usuários e computadores distintos, por
meio do uso de disquetes;
d) os computadores eram de uso pessoal e geralmente executavam apenas
uma tarefa por vez;
e) o hardware normalmente era limitado: não realizava de forma eficiente o ge-
renciamento de memória, por exemplo.
Com as características descritas acima, surgem os sistemas operacionais. Um
sistema operacional monotarefa (executava apenas uma atividade ou programa
por vez) e monousuário (a máquina pertencia apenas a uma pessoa – não ha-
via mecanismo de autenticação, com senha e nome de usuário, por exemplo).
Requisitos de segurança de acesso, conforme ISO/IEC 17799, simplesmente não
eram praticados. Os sistemas operacionais eram muito simples, tinham um mó-
dulo de gerência de processo simplificado, com o escalonador quase inexistente,
gerenciamento de memória sem suporte à paginação e sistema de arquivos sem
38
atributos de proteção. Como herança desse modelo, temos ainda o vírus compu-
tacional, devido à incapacidade de o sistema operacional se proteger de progra-
mas maliciosos.
C) REDE DE COMPUTADORES
Denis Pacher (2012)

Figura 19 - Computadores em rede
Com o crescimento do uso de computadores pessoais e pelos problemas que

eles estavam enfrentando, em especial questões de segurança e compartilha-
mento de dados e periféricos, foram introduzidos os sistemas operacionais de
redes (NOS - Network Operating System) que tinham como foco principal o com-
partilhamento de arquivos e de periféricos, em especial as impressoras. Visando
a permitir esse compartilhamento de forma segura, o conceito de identificação
(com emprego de nome de usuário e senha) é introduzido no sistema.
Na década de 80, a empresa Sun Microsystem, hoje, parte da Oracle, em seu
sistema operacional SunOS, criou as bases do que seriam os diversos outros siste-
mas do mercado, introduzindo o conceito de base de autenticação centralizada,
o Network Information Service (NIS), e de arquivos em rede, o Network File System
(NFS), bem como um middleware para desenvolvimento em rede, o Remote Pro-
cedure Call (RPC).
d) SISTEMAS DISTRIBUÍDOS
Denis Pacher (2012)
Figura 20 - Sistema distribuído

39
Na década de 90, o foco deixou de ser o compartilhamento de dados, pois o

aumento da capacidade das máquinas permitiu que fosse praticado o conceito
de sistema distribuído – sistema em que o foco está no compartilhamento entre
as máquinas interligadas em rede. Nesse caso, os principais elementos são CPU
e memória, em detrimento de periféricos e arquivos dos NOS. Os sistemas ope-
racionais que permitiam o suporte à operação distribuída foram denominados
Distributed Operating System (DOS), sendo de responsabilidade desses sistemas a
função de executar, além dos quesitos dos sistemas operacionais de redes, aspec-
tos como replicação e memória global. Nessa fase, diversos produtos surgiram no
mercado e quase todos eram baseados em Unix.
e) SISTEMA DE TEMPO REAL Dreamstime (2012)
Figura 21 - Exemplo de sistema de tempo real
Os sistemas operacionais de tempo real têm como principal função o suporte

ao atendimento de solicitações de forma rápida, não gerando atrasos em siste-
mas críticos. O principal aspecto está em um escalonador de processos especiali-
zado. Essa necessidade surge quando pensamos na automação de um semáforo
de trânsito, por exemplo, em que o sistema operacional, em tempo real, deve
garantir que um sinal fique vermelho e o outro verde, pois se essas atividades não
forem executadas em tempo real, poderá ocorrer um acidente. No estudo dos
diversos tipos de escalonadores, no gerenciamento de processo, esse conceito é
enfatizado. Citamos aqui o sistema QNX e RTOS.
40
f) SISTEMAS EMBARCADOS
6 I/O bound
É um termo utilizado para

designar os sistemas que
fazem uso intensivo de
entrada/saída (I/O).
Dreamstime (2012)
Figura 22 - Exemplo de Sistema embarcado
Com o crescimento do uso de hardware embarcado (um computador de uso

específico), temos o desenvolvimento de sistemas operacionais para esse tipo de
sistema computacional. Suas principais características são o tamanho reduzido e
a capacidade de lidar, muitas vezes, com um gerenciamento de memória simpli-
ficado na CPU.
Existem diversos sistemas desenvolvidos para esse tipo de ambiente, bem
como variantes de sistemas tradicionais do Windows (Windows CE/móbile) e do
Linux. No mercado, hoje, uma variante do Linux (que é baseado no Unix) tem so-
bressaído e assumido a liderança do mercado, o Google Android.
Vimos, neste tópico, a diferença entre sistemas computacionais e sistemas
operacionais. Você entendeu a analogia inicial do campo de futebol com nossos
computadores? Se tiver um sistema computacional, necessita-se de um sistema
operacional que gerencie esse ambiente. Se tiver um celular/smartphone, neces-
sita-se de um sistema operacional específico para esse ambiente, que é ligeira-
mente diferente do sistema para um mainframe, por exemplo, ainda que todos
preservem as mesmas premissas de gerenciamento.
Além dos sistemas vistos aqui, existe o Cloud computing, a chamada computa-
ção em nuvem, que é uma tendência na internet do futuro.
2.1.6 HISTÓRICO DE SISTEMAS OPERACIONAIS: DO MONITOR À

MULTITAREFA
Ao deparar-se com os diversos tipos de ambientes computacionais e sistemas

operacionais, você deve estar se perguntando como podemos ter várias aplica-
ções executando em um mesmo sistema operacional, como o Linux ou Windows,
certo? Você sabe como eles são implementados? É o que veremos agora! Discuti-
41
remos como os conceitos de alguns sistemas operacionais foram incorporados na

computação, veremos como algumas aplicações computacionais se comportam
e teremos a oportunidade de perceber como o computador evoluiu – evolução
conjunta com os sistemas operacionais e com os hardwares.
Antes de começar nosso estudo sobre sistemas de multitarefas, você precisa
conhecer alguns conceitos que serão empregados ao longo deste tópico.
CONCEITOS BÁSICOS DE APLICAÇÃO
a) Processo: no contexto da informática, processo é um programa (uma apli-

cação) de computador em execução. Diferente do código executável em
disco, o processo possui também áreas de trabalhos (buffers, memória para
variáveis, arquivos abertos, dentre outros). Um processador de texto ou um
navegador internet em execução são exemplos de processos.
Ao longo do tempo, caracterizaram-se dois tipos de comportamento de apli-
cações: CPU bound e I/O bound.
b) CPU bound: uma aplicação que, na maior parte do tempo em que está sen-
do executada, faz uso do processador. Esta aplicação raramente acessa peri-
féricos, ou seja, não necessita de entrada e saída. Como exemplo desse tipo
de aplicação, podemos citar aplicações científicas de simulação e aplicações
de conversão de vídeo de um formato para o outro.
c) I/O bound6: a principal característica deste tipo de aplicação é que o uso de
processador é muito pequeno. Este sistema faz uso intensivo de entrada e
saída na maior parte do seu tempo de execução. Podemos citar como exem-
plo uma aplicação de folha de pagamento, que gasta mais tempo emitindo
um relatório do que fazendo cálculos. Inicialmente, até meados da década
de 70, a maior parte das aplicações em uso era I/O bound.
Vimos os dois tipos de aplicações acima, mas ainda não sabemos como inte-
ragir com cada uma delas. Você sabe como acontece o acesso a essas aplicações?
Para interagirmos com essas aplicações, temos dois sistemas disponíveis:
a) Sistema Interativo
Neste sistema, a aplicação é colocada na memória. A execução e a entrada
de dados na memória são feitas pelo usuário, por meio de um periférico –
um teclado ou mouse, por exemplo – e os resultados são mostrados na tela.
Convencionou-se chamar de terminal o conjunto de teclado, mouse e mo-
nitor (o mouse só foi introduzido nessa nomenclatura no final da década de
70). Grande parte das aplicações atuais é interativa, como as aplicações web,
o telebanking ou aplicações de gestão de documentos empresariais.
42
b) Sistema batch
Nos sistemas batch, ou de lote, a aplicação era colocada na memória e os da-
dos que alimentavam a aplicação eram postos de forma pré-gravada em um
dispositivo de entrada. No primeiro momento, os dados eram codificados
(da mesma forma que o programa) em cartões perfurados que eram lidos
no computador. No segundo momento, com o uso de armazenamento se-
cundário, os dados eram gravados em arquivos e o software, quando execu-
tado, lia esses arquivos. O resultado dessa execução também era gravado
em arquivos. Uma característica interessante é que o usuário do sistema não
precisa estar disponível para a execução da aplicação, permitindo que a exe-
cução seja feita no momento adequado para a empresa que cuida da parte
de informática. Esse tipo de processamento foi o modo primário de trabalho
dos chamados mainframes. Esse sistema ainda é bastante utilizado para con-
solidar réplicas de bancos de dados, dentre outras aplicações.
O PROGRAMA MONITOR
Você já deve ter se deparado com o termo “monitor” diversas vezes. Utilizare-
mos esse termo a um tipo de sistema operacional.
O sistema operacional, em sua versão mais simples, ficava residente no har-
dware desempenhando o papel de ler o deck de cartão na entrada, colocar em
execução, ler a nova tarefa, e assim repetitivamente – assumiu o nome de pro-
grama monitor.
Ele desempenhava basicamente tarefas de entrada e saída, pois os sistemas
computacionais da época eram muito simples e permitiam apenas uma execu-
ção por vez. Os periféricos eram essencialmente deck de cartões e impressoras.
Apenas uma tarefa era colocada em execução e a CPU só era liberada quando
essa tarefa era finalizada. Tínhamos um sistema monotarefa e monousuário, sem
suporte a escalonamento. A principal característica das aplicações dessa época
era I/O bound do tipo batch.
SISTEMAS MULTITAREFA
Percebendo que grande parte das aplicações tinha como característica o tipo
batch e I/O bound que passavam mais tempo fazendo entrada e saída do que
usando o processador (CPU), e que o custo da CPU era muito alto para ela ficar
parada, os cientistas da computação passaram a focar em uma solução para este
problema: como usar o hardware ao máximo?
43
A solução encontrada foi uma estratégia criativa e antiga: o compartilhamen-

to de recursos. A ideia foi incrementar o programa monitor de tal forma que os
recursos (CPU, deck de cartão, impressora etc) funcionassem como caixas de um
supermercado. Para cada caixa de supermercado ou, no caso, para cada recurso
computacional, deveria ser construída uma fila.
Fila, no campo computacional, uma fila constitui-se em uma estrutura de da-
dos em que podemos realizar duas operações: inserção (sempre no final da fila) e
retirada de elementos (sempre no início da fila). Normalmente, denominamos essa
abordagem de first in first out (FIFO) – o primeiro que entra é o primeiro que sai.
Importante: em computação, não existe a possibilidade de furar a fila.
Denis Pacher (2012)

Saída entrada
Figura 23 - Fila
Fonte: O Autor
A montagem das filas (figura acima) funcionava da seguinte maneira: um pro-

grama que precisaria ser executado era colocado na fila de cartões. Quando che-
gava a sua vez, ele era lido pela memória e executado. Se fosse necessário o uso
de algum periférico, o programa deixava a CPU livre e ia para a fila associada ao
periférico, dando espaço para que uma nova aplicação fosse lida no deck de car-
tões. Quando a aplicação terminava sua atividade de entrada e saída, voltava para
a fila de espera da CPU.
Dessa forma, podemos ter diversas aplicações em execução, aproveitando a
ociosidade da CPU.
DESEMPENHO E CUSTO
É necessário atentar para o impacto da implementação das filas, já que ante-

riormente tínhamos apenas um programa em execução, ou na memória do com-
putador, e agora podemos ter vários. Com essa mudança, surgem alguns ques-
tionamentos:
a) O ato de implementar as múltiplas filas e o ato de mover os programas entre
elas não gera gasto de recursos? Gera gasto de recursos (tempo de processa-
mento) e de memória para implementar as filas de gerência.
b) Um processo que estava sendo executado e foi para o I/O, quando termina
o I/O não deveria assumir a CPU de imediato? Não pela definição de fila. Um
processo somente libera a CPU quando terminar ou quando for para I/O.
44
c) Se tiver vários processos em memória, o gerenciamento de memória não

complica? Complica e muito, bem como as preocupações com segurança
advindas disso.
Em suma: o ato de termos um gerente de recursos, o sistema operacional, con-
some recursos.
Vamos recapitular o que vimos até aqui? Você deve ter compreendido que po-
demos ter várias aplicações usando um único computador (CPU), não é mesmo?
Isso só é possível por meio do mecanismo de multitarefa: quando um programa
sai para o I/O, colocamos outro na fila para executar e, dessa maneira, utilizamos
melhor o hardware. Podemos dizer que a introdução de multitarefa leva à cha-
mada gerência de memória em sistemas operacionais, bem como efetiva a noção
de controle de processos (programas em execução). Você já está começando a
entender como o computador funciona, não é mesmo? Vamos em frente!
2.1.7 HISTÓRICO DE SISTEMAS OPERACIONAIS: SISTEMAS DE TEMPO

COMPARTILHADO E MULTIUSÁRIO.
Você já observou se o seu computador consegue executar outro programa en-

quanto os periféricos de entrada e saída estão sendo utilizados, por exemplo, em
uma impressão? Já se perguntou como o computador executa ao mesmo tempo
o Windows, antivírus, editor de textos e programa de desenho, sem estarem utili-
zando periféricos de entrada e saída? Partindo dos conceitos de Von Neumann, a
CPU executa uma instrução depois da outra e nunca duas ou mais instruções ao
mesmo tempo. Então, qual o mistério? Bom, não existe mistério, mas pequenos
“truques”. Neste tópico, vamos discutir sobre o sistema multiusuário e multitarefa.
HISTÓRICO DE SISTEMAS OPERACIONAIS: SISTEMAS MULTIUSUÁRIOS
O aparecimento da multitarefa trouxe soluções que permitiram o uso da com-

putação de forma comercial, bem como avançar na separação do hardware e do
software, deixando algumas tarefas para o sistema operacional e levando ao de-
senvolvimento de suas funcionalidades. Contudo, dois problemas persistiram:
gerência do tempo de uso da CPU e segurança.
Na questão de gerência do tempo da CPU, temos, dado o ambiente multitarefa,
a seguinte situação: um processo assumia a CPU e só liberava em duas situações,
quando terminava ou quando necessitava de um recurso de I/O (Entrada/saída,
em inglês: Input/output, sigla I/O). Se o programa apresentasse falha de projeto ou
se houvesse um usuário mal-intencionado, poderia ocorrer a posse eterna da CPU.
45
A questão de segurança também surge quando pensamos em programas de

empresas distintas sendo executadas na mesma máquina. As empresas teriam suas
informações compartilhadas e as duas veriam dados que não lhe pertenciam.
Um terceiro aspecto que surge, não diretamente relacionado aos anteriores,
é o aparecimento de novos dispositivos de hardware e periféricos para entrada
e saída. Com o conceito de terminal remoto, um dispositivo contendo teclado,
monitor e, algumas vezes, impressora, permitia acesso em tempo real ao com-
putador – mainframe. Nessa época, surge o conceito de modelo de computação
interativa em detrimento ao de batch, que ainda continuou sendo muito usado.
Saber que uma aplicação de um usuário conectado ao mainframe via terminal
remoto tinha que esperar outra tarefa terminar ou ir para I/O antes de poder exe-
cutar, nos leva a pensar nos imensos retardos que isso levaria.
O QUE FAZER?
Antoine Lavoisier afirmava que “Na natureza nada se cria, nada se perde, tudo se
transforma”. Talvez você não concorde com essa lei e prefira uma visão de mundo
que foi cantada pelos Engenheiros do Hawaii, em Além dos Outdoors, “...As coisas
mudam de nome, mas continuam sendo religiões As coisas mudam de nome, mas
continuam sendo o que sempre são...”. Vamos considerar que tudo se transforma
e, se conhecer os fundamentos do que foi transformado, terá uma chance de rea-
proveitá-lo sem ter necessidade de criar algo novo.
Veremos uma ideia antiga: a multiplexação por tempo, normalmente discu-
tida na área de redes de computadores ou telecomunicações, mas que pode ser
exemplificada de forma simples.
Como usar uma sala de aula?
Denis Pacher (2012)
Figura 24 - Sala de Aula

46
Imagine uma sala de aula em uma escola que possui aulas nos três turnos. O
7 Time slice que fazer com essa sala para utilizá-la melhor e acomodar as atividades requeri-
Constitui a unidade de
das? Você poderia pensar em algumas alternativas, acompanhe.
tempo alocada para cada
processo em execução. É a) Primeira opção - uso exclusivo: a escola decide que só uma turma pode
o elemento básico para o utilizar a sala de aula. Quando essa turma entrar, só sairá dela quando as ati-
escalonamento.
vidades terminarem. Várias turmas poderão usá-la desde que seja liberada
pela turma que a utiliza, liberando-a no final do turno ou enquanto a turma
estiver numa aula de educação física, por exemplo.
b) Segunda opção - janelas de aula: a escola decide que existem horários de
uma hora para cada aula. Cada turma pode usar essa sala por uma hora. Pas-
sando esse tempo e ninguém estiver esperando para usá-la, a turma pode
ficar mais uma hora. Se alguém chegar e a turma já estiver em aula, deverá
esperar na fila, fora da sala. Se a turma que estava lá não terminar as ativida-
des previstas dentro de uma hora, deverá retornar para a fila e esperar sua
próxima vez.
c) Terceira opção - dividir a sala em partes menores: se a sala for muito gran-
de, podemos dividi-la e acomodar mais de uma turma ao mesmo tempo. Em
cada subsala, programar a opção um ou dois, citada acima.
Na primeira opção, não existe compartilhamento do recurso: alguém pega e
usa até o final. Isso lembra o cenário dos sistemas operacionais monotarefa, não
é mesmo?
Na segunda opção, o tempo de uso da sala é dividido e usamos uma regra para
controlar o seu uso – no nosso caso, uma fila. Poderíamos ter outros mecanismos,
como algo que implementasse prioridade: se o diretor da escola chegasse com
uma turma de alunos, por exemplo, ele teria direito de utilizar a sala antes. Nesse
caso, criaríamos fatias de tempo (slices) que seriam alocadas – é o que chamamos
de multiplexação no tempo.
Na terceira opção, dividimos a sala em partes e vários usuários poderiam usu-
fruí-la ao mesmo tempo. Neste caso, aplicam-se as premissas 1 (ficar enquanto
quiser) ou 2 (dividir cada subsala em janelas de tempo para uso). Esse tipo de
multiplexação de recurso, em que dividimos o recurso em partes para atividades
específicas, é chamado de multiplexação em frequência.
Contexto da atividade:
Uma questão que surge se adotarmos a opção 2 é: se a janela de tempo de
uma turma é finalizada, ela deve desocupar a sala, mesmo que as tarefas ainda
não tenham sido finalizadas. Mas o que fazer com as anotações do quadro negro?
O que fazer com a organização das cadeiras?
Bom, a solução consiste em salvar uma cópia desse estado da sala, uma foto ou
snapshot, para que quando a turma voltar para a sala, isso seja restaurado –poderí-
47
amos deixar o zelador da escola cuidando dessa atividade, por exemplo. Fica claro
que a ideia de dividir a sala em janelas de tempo de uso gera gasto de recursos.
Denominamos essas informações pertinentes a um estado de execução de
uma atividade de contexto.
Se voltarmos nossa atenção para a computação e pensarmos na implementa-
ção de multitarefa em sistemas operacionais, é essencial que lidem com o contex-
to de cada programa em execução.
Qual seria uma boa solução para a computação?
As três soluções são viáveis, tudo vai depender do seu objetivo. Se pensarmos
no problema de usar adequadamente o computador com vários programas em
execução, a opção 2, multiplexação no tempo, mostrou-se a mais adequada.
A ideia básica consiste em, empregando o relógio de tempo real da máquina,
marcar janelas de tempo, de n milissegundos, por exemplo, sendo que execu-
tamos o conceito de multitarefa, mas com a característica de que um programa
em execução fica usando da CPU apenas uma janela de tempo (time slice7). Um
módulo do sistema operacional, o escalonador, cuida dessas filas e implementa o
controle de tempo.
$$ $
$
$ $ $$ $$
$ $ $$
$ $ $ $
$ $ $
Denis Pacher (2012)
$$
$
$ $
Figura 25 - Time slice
Surge o que denominamos de sistema de tempo compartilhado (timesharing),

que aliado à multitarefa e é a base dos sistemas operacionais atuais – sistemas
operacionais multiusuários.
E a questão de segurança?
Para melhorar a segurança, foi necessário aperfeiçoar o gerenciamento de me-
mória para que uma aplicação esteja protegida das demais. Outra necessidade foi
a criação de perfis de usuários, em que cada um usasse apenas os recursos que
diziam respeito a sua função.
48
SISTEMAS OPERACIONAIS ATUAIS

8 Kernel do sistema
operacional Atualmente, quase todos os sistemas operacionais são implementações multi-
Parte central do sistema tarefa, multiusuário e de tempo compartilhado. Da Microsoft, o Windows na pla-
operacional. taforma New Tecnology (NT), que está disponível nos servidores Windows e no
sistema operacional desktop desde o Windows XP, apresenta suporte multitarefa
e tempo compartilhado, permitindo vários usuários.
O Unix, desde a sua criação, possui a característica de ser multitarefa multiu-
suário e ter tempo compartilhado. O mesmo ocorre com as suas variantes: o BSD
Unix, o Linux e o Google Android.
Você já compreendeu que não existe mágica na implementação de um siste-
ma multitarefa/multiusuário, apenas o uso de técnicas adequadas que permitem
a multiplexação no tempo dos diversos processos que executam. Agora, enten-
deu que os processos executados, embora o usuário do sistema acredite que es-
tão sendo feitos ao mesmo tempo, estão divididos em fatias de tempo muito pe-
quenas. Vimos ainda que o ato de gerar essa divisão de tempos e de deixar vários
programas executando na CPU leva alguns gastos: gastos com a implementação
do processo e, em especial, com a implementação de salvar e restaurar o contex-
to dos processos no final de cada fatia de tempo (time slice).
2.1.8 SISTEMA OPERACIONAL - ORGANIZAÇÃO
Você já sabe como os sistemas operacionais funcionam, não é mesmo? Sabe

também que um sistema operacional possui milhares de rotinas internas que os
aplicativos dos usuários podem chamar para realizar tarefas básicas.
Vamos descobrir, neste tópico, como seus diversos blocos se encaixam, ou
seja, como é organizado um sistema operacional. Essa informação nos ajudará a
compreender melhor o seu funcionamento.
ORGANIZAÇÃO DO SISTEMA OPERACIONAL
Quando falamos em um sistema operacional, normalmente levamos em conta

diversos recursos do hardware e as abstrações que queremos implementar. Você
lembra quais são eles? Podemos pensar em módulos ou gerentes:
a) Gerente de processo: responsável por programar a multitarefa e o tempo
compartilhado no uso da CPU, tendo como parte principal o escalonador;
b) Gerente de memória: responsável por gerenciar a memória principal, alo-
cando-a aos muitos processos em execução e cuidando para efetuar o con-
ceito de memória virtual;
49
c) Gerente de arquivos: responsável por implementar os conceitos (abstra-

ções) de arquivos, diretórios e subdiretórios;
d) Gerente de I/O: responsável por tratar do relacionamento com os diversos
periféricos.
Nas descrições acima, temos clara a função de cada gerente (ou módulo) no
sistema operacional. Mas algumas questões necessitam ser apresentadas: como
esses módulos estão interligados? Para representar graficamente um sistema
operacional, devemos lembrar que na fase inicial suas funções estavam no moni-
tor, todas centralizadas em um único bloco de código, normalmente escrito em
uma linguagem Assembly de baixo nível, especificada no processador. Ao longo
do tempo, os diversos gerentes foram sendo aprimorados e incrementados, ten-
do no centro o núcleo ou kernel do sistema operacional8, que integra as funções
de interfaceamento com a máquina física/hardware, integrando o gerenciamento
de processos (escalonador) e o gerenciamento de I/O. Em um nível acima, temos
o gerenciamento de memória, gerenciamento de processos e gerenciamento de
arquivos. Em seguida temos os usuários (aplicações do usuário).
A linguagem Assembly também é conhecida como lin-

VOCÊ guagem de montagem, sendo especifica de cada pro-
SABIA? cessador. Cada comando no Assembly está associado a
uma instrução da máquina.
O espaço de memória que o sistema operacional ocupa deve ser protegido e

somente esse sistema poderá alterar os dados nesse espaço. Dados esses precei-
tos, veja a representação de um sistema operacional na figura abaixo:
Modo usuário
API do SO - Maq virtual
Modo kernel
Ger. Ger.
Arquivo Memória
Ger.
Processo
Escalonador
Ger.
I/O kernel
Denis Pacher (2012)
Acesso a memória física
Hardware
Figura 26 - Organização de sistema operacional

Fonte: Autor
50
a) No nível mais baixo está o hardware do computador, que só pode ser aces-
9 Modularização sado via sistema operacional, garantindo que, se o sistema for multitarefa/
Em tecnologia da
multiusuário, não haja interferência entre os processos em execução.
informação, é um conceito
onde o sistema ou software b) No nível acima do hardware tudo está em memória é software. A diferença é
é divido em partes distintas que parte será o sistema operacional e parte aplicações de usuários. A linha
verde indica essa separação: o que está abaixo dela é sistema operacional
e acima, aplicações do usuário. Programas que conseguem rodar nesse es-
paço baixo de memória do sistema operacional, chamamos de processos
em modo kernel e, quem está acima, chamamos de processos em modo
usuário ou espaço do usuário. A separação desse espaço é implementada
via mecanismo de paginação do processador.
c) Voltando ao diagrama, acima do hardware temos o kernel do sistema opera-
cional, onde estão presentes o suporte ao dispositivo de I/O (gerente de I/O)
e o acesso básico ao hardware de memória e escalonador. Podemos notar
os diversos gerentes (processo, memória e arquivo) que usam suas funções
entre si e fazem uso do kernel para acessar o hardware.
d) Após os gerentes, logo acima da linha verde, temos no espaço do usuário a
Application Program Interface (API) para uso das funções do sistema opera-
cional, que ocorre por meio do mecanismo de interrupção. O sistema ope-
racional altera o vetor de interrupções do hardware e coloca determinadas
interrupções apontando para dentro do código do sistema operacional.
Uma aplicação do usuário pode invocar uma interrupção do processo, por
exemplo, na arquitetura IA32, via instrução INT do processador.
Normalmente, acima dessa API, que funciona como o hardware que nossos
programas veem (uma máquina virtual), estão as aplicações dos usuários ou al-
gum mecanismo de acesso, denominado de shell (em analogia a uma concha, que
esconde e encapsula o que está dentro dela). Existem diferentes tipos de shell:
a) shell textual: como o Command.com no MS DOS, CMD no Windows ou
bash no Unix;
b) shell gráfica: como no Windows ou no Unix sendo sua interface denomina-
da Graphic User Interface (GUI).
Vamos recapitular o que vimos? Você aprendeu como os diversos blocos se
encaixam na ótica de prover e usar serviços. Viu que normalmente o acesso ao sis-
tema operacional é feito via uma API padronizada, implementada via mecanismo
de interrupção. Esse é um passo importante na compreensão do funcionamento
de sistemas operacionais. Continue atento e vamos em frente!
51
2.1.9 SISTEMA OPERACIONAL MONOLÍTICO, MODULAR E

MICROKERNEL
Sabemos como os sistemas operacionais funcionam e como estão organiza-

dos de uma forma geral. Antes de trabalharmos alguns produtos de mercado é
importante conhecermos algumas características do sistema operacional no que
se refere à implementação. Lembre que um sistema operacional é um software e,
como tal, foi escrito por pessoas usando diversas técnicas de desenvolvimento.
Nesse processo de desenvolvimento, algumas vezes opta-se em produzir o siste-
ma operacional como um grande código ou modularizá-lo9.
COMO IMPLEMENTAR?
Dreamstime (2012)
Figura 27 - Implementação de software
Um fato importante é que os sistemas operacionais até o ano de 1972, com

o lançamento do Unix escrito em C, eram escritos em linguagem de baixo nível
(Assembly) do computador em que iria ser executado. Normalmente, a linguagem
Assembly (década de 50 a 70) não oferecia instruções de modularização, permi-
tindo as implementações primitivas de alto nível, como um goto (via instrução
jumper). Modularizar um programa e fazer a passagem de parâmetros em baixo
nível era relativamente difícil.
Um software pode ser desenvolvido de duas formas, como veremos a seguir.
a) No início do programa, você declara as variáveis que serão usadas em to-
dos os módulos como globais e depois começa a escrever o código, que
pode ser modular, empregando preceitos de programação estruturada.
Nessa programação, usamos a divisão do programa em módulos chamados
de funções ou procedimentos, ou simplesmente se desvia a execução para
onde desejar por meio de uma instrução como o goto (desvio incondicio-
52
nal para outro local no código do programa). Nesse caso, como as variáveis
que os diversos módulos empregarão são globais, não há necessidade de se
passar parâmetros entre os módulos, tornando a execução mais rápida. Se
pensarmos em usar apenas um grande bloco com gotos, não faz sentido a
passagem de parâmetros. Quando se aprende a programar computadores,
independente da linguagem, o que descrevemos é duramente criticado por
gerar um código totalmente dependente entre suas partes e por ser de difícil
manutenção, ainda que seja extremamente eficaz.
b) Você pode modularizar seu software em blocos. Assim, tudo que for passa-
do entre os blocos, sejam procedimentos, funções ou objetos em programa-
ção orientada a objetos, é explicitamente passado como parâmetro, fazendo
com que exista uma relativa independência entre os módulos, permitindo
a evolução de um módulo independente dos outros ou até a sua completa
substituição. Uma característica que normalmente é omitida é de que a mo-
dularização com passagem de parâmetros torna o código mais lento.
Observe abaixo a figura que representa a organização de um sistema opera-
cional:
Modo usuário
Modo kernel
Ger. Ger.
Arquivo Memória
Ger.
Processo
Escalonador
Ger.
I/O kernel
Denis Pacher (2012)
Hardware
Figura 28 - Organização de sistema operacional
Dadas duas opções de desenvolvimento de software, você saberia dizer qual

delas é empregada no desenvolvimento de um sistema operacional?
A resposta, devido à importância do sistema operacional, é a segunda opção:
modularização. Mas esse não foi o caminho tomado no desenvolvimento de sis-
temas operacionais. Vamos entender a razão!
53
Como vimos, até a década de 70, os sistemas eram escritos em linguagem As-
sembly por questão de desempenho. O Assembly não permite implementar mo-
dularização com variáveis locais de forma muito simples. A opção foi natural. O
programa monitor foi crescendo, agregando funções, foi sendo dividido em ge-
rentes funcionais, mas o código era somente incrementado. Uma chamada do ge-
rente de arquivo ao gerente de memória, basicamente, colocava os valores dese-
jados em uma área de memória (variável) e era feito um goto para o outro gerente
e depois outro goto de volta. Simples, eficaz e fácil de perder – mudar uma linha
de código no sistema operacional poderia levar a efeitos colaterais em escala. A
figura abaixo representa como ficaria nosso sistema operacional nesse contexto.
Chamamos essa abordagem de desenvolvimento de Sistema operacional mo-
nolítico ou simplesmente kernel monolítico. Exemplos de sistemas operacionais
desse tipo são o Unix e o Windows.
Modo usuário
Ger. Ger. Ger.

Arquivo Processo Memória
Escalonador
Ger.
I/O kernel
Denis Pacher (2012)
Hardware
Figura 29 - Kernel monolítico
Com o começo do Unix (o primeiro sistema operacional escrito em lingua-

gem de alto nível C), a implementação de modularização parece natural. Uma
alternativa seria que cada gerente fosse visto como um módulo independente,
abordagem denominada de kernel modular. As versões mais atuais do Unix e do
Windows seguem essa tendência.
Na década de 80, com o surgimento das redes de computadores e do desen-
volvimento de software baseado no modelo de objetos, surgiu a ideia de deixar
apenas o kernel do sistema operacional em modo kernel. Um kernel totalmente
independente dos diversos gerentes, de tal forma que uma máquina não tivesse
sistema de arquivo local e nunca fosse fazer uso dessa característica, podendo ter
no seu sistema operacional a ausência desse módulo sem prejuízo. Em compen-
sação, um servidor de arquivo poderia executar diversos gerentes de arquivos,
fornecendo visões de arquivos para o Unix , Windows ou outros sistemas opera-
54
cionais. Essa é a abordagem de Microkernel. Um exemplo desse tipo de imple-

mentação é o Windows NT e o Unix OSF/1, tendo ainda representantes como o
QNX, MACH, e Chorus.
Agora que você conheceu as diversas formas de organizar um sistema ope-
racional, ficou mais claro o impacto de um erro de desenvolvimento no funcio-
namento de um sistema operacional e a dificuldade de manter o código de um
sistema monolítico estável. Uma questão importante é de quanta memória um
sistema operacional gasta, um sistema baseado em microkernel gasta bem me-
nos recursos que os demais. E então, pronto para seguir em frente? Continue
acompanhando!
2.1.10 SISTEMA OPERACIONAL MULTIPLATAFORMA: UNIX
Você sabia que quando a informática começou, cada computador era dese-
nhado para uma atividade específica (seu hardware e seu sistema operacional)?
Havia máquina para o comércio, para a indústria, para a pesquisa científica etc.
Imagine o custo para manter esse desenvolvimento de ambientes diferentes para
uma empresa como a IBM, na década de 50.
Era necessário fazer algo! Discutiremos, neste tópico, que caminhos a informá-
tica tomou a partir da década de 50 e que, hoje, tornaram-se o padrão do merca-
do. Viajaremos, agora, na bela história do sistema operacional Unix – o “pai” dos
sistemas operacionais atuais.
MULTICS
Figura 30 - Multics
Fonte: http://www.multicians.org/mulimg/kl-cisl-multics-rug.jpg
55
Na década de 60, um conjunto de empresas (Boeing, GE e AT&T) atuantes em

diferentes áreas estabeleceu um consórcio que pretendia desenvolver um siste-
ma computacional de uso geral, que seria usado em qualquer ambiente, desde
o chão de fábrica até a operação de uma empresa. A proposta era desenvolver
o hardware e o sistema operacional. Dada a variedade de usos da plataforma
pensada, a proposta de nome para o sistema operacional foi Multics (Multiplexed
Information and Computing Service - <http://www.multicians.org/history.html>),
cabendo seu desenvolvimento ao Bell Labs da AT&T, GE e MIT. O projeto não teve
o sucesso esperado, mas as ideias desenvolvidas foram importantes na evolução
de sistemas operacionais que continuaram ativos até a década de 90.
UNIX
Em 1969, Ken Tomphson e equipe, no Bell Labs da AT&T, desenvolveram para

o minicomputador DEC PDP-7, usando a linguagem Assembly dessa máquina, um
sistema operacional que era uma versão simplificada do projeto Multics, em que
tinham trabalhado anteriormente. Chamaram seu sistema operacional de Unics.
Em 1973, o Unics foi reescrito na linguagem de programação C e portado para
um minicomputador da mesma família de hardware, mas com maior capacidade,
o PDP-11. A linguagem C chamava atenção por ser uma evolução da linguagem
B (esta, por sua vez, era uma linguagem de programação funcional, estruturada
e com grande capacidade de acesso ao hardware em baixo nível). A implementa-
ção do sistema operacional foi denominada Unix. Nascia a lenda Unix e morria o
mito de que sistemas operacionais deveriam ser escritos em linguagem Assembly.
Portal Linux&Unix
Figura 31 - Ritchie e Thompson, dois dos desenvolvedores do Unix

Fonte: http://cm.bell-labs.com/cm/cs/who/dmr/kd14.jpg
56
Apenas um pequeno problema existia para o sistema desenvolvido: a AT&T,

por força de lei, não podia comercializar um sistema operacional, por já comer-
cializar produtos de telefonia. Esse impedimento era devido à regulamentação
americana que tentava evitar o monopólio no mercado.
Então, o sistema operacional foi repassado à Universidade da Califórnia, cam-
pus de Berkeley. Na universidade existiam diversos computadores diferentes,
sendo que rapidamente o Unix foi portado com facilidade para esses diferentes
hardwares, sempre apresentando bom desempenho.
Em 1974, a AT&T/Bell Labs obteve autorização para comercialização de produ-
tos de informática, e retomou o código entregue a Berkeley, incluindo as melho-
rias. Entretanto, a universidade pôde continuar desenvolvendo e usando o siste-
ma operacional em que havia trabalhado e dado grandes contribuições.
Considerando a área de atuação, em ensino e pesquisa, e a preocupação com a
responsabilidade pelos problemas que resultariam pelo uso do Unix, a alternativa
foi desenvolver uma licença para repasse do sistema operacional Unix, que estava
em mãos de Berkeley. Essa licença foi denominada de licença Berkeley Software
Distribution (BSD), ficando o Unix de Berkeley denominado de BSD Unix e a versão
de posse do Bell Labs de AT&T Unix. Quanto ao Unix: o que ele tem de tão especial?
O Unix possui uma característica de ser escrito na linguagem C. Para levar
um programa escrito em C de um computador para outro totalmente diferente,
precisamos apenas de um compilador C na nova máquina. Como o Unix estava
escrito em C, então, além de um compilador C para o novo hardware em que se
desejava levar esse software, era preciso realizar pequenos ajustes para o novo
ambiente, devido a sua particularidade de ser um sistema operacional. Estava
criado o conceito de sistema operacional multiplataforma. Podíamos ter o proje-
to de um novo hardware e manter o sistema operacional. Os desenvolvedores de
software e usuários de computadores não precisavam aprender a usar um novo
SO toda vez que um novo hardware era desenvolvido. Bastava compilar o Unix
para o novo hardware e usar. Ele foi o primeiro a utilizar essa abordagem, mas,
posteriormente, diversos sistemas operacionais fizeram isso também.
EVOLUÇÃO DO UNIX E AS GUERRAS UNIX
O sistema Unix passou a ser distribuído ao mercado em duas versões: a co-

mercial com código fechado da AT&T e a versão “acadêmica” de código aberto,
o BSD Unix.
O Unix com sistema multiplataforma e de código aberto foi adotado rapida-
mente nas universidades para trabalhos e projetos, sendo que a primeira versão
dos protocolos para internet TCP/IP foram implementados no kernel do Unix,
57
tornando-o quase o sistema padrão da internet no futuro. Podemos dizer que o

Unix e a internet nasceram e cresceram juntos. O sistema operacional evoluiu, e
enquanto o BSD Unix, em sua versão 4, tinha como ponto alto a parte de suporte
à rede, o sistema da AT&T em sua versão 5, o Unix System V, tinha como elemento
forte a gerência de memória.
Por existir duas versões de Unix no mercado, começou uma disputa de qual
era a melhor. Disputa essa entre os melhores desenvolvedores de software no
planeta. Os usuários, administradores e desenvolvedores de uma versão de Unix
gastavam tempo e esforços razoáveis buscando falhas na versão concorrente –
esse comportamento foi conhecido como Unix Wars, e durou a década de 70 e
80. O que seria ruim tornou-se bom, pois talvez tenha garantido a estabilidade e
robustez do sistema operacional Unix: não necessitava de ninguém externamen-
te para tentar comprometer a segurança ou estabilidade do sistema operacional,
pois os usuários da versão irmã do sistema eram responsáveis por isso, e o com-
portamento de verdadeiras tribos guerreiras era adotado, quase como que uma
religião. O sistema Unix resistiu, e hoje é a base de todos os demais.
Como versões marcantes do Unix BSD, temos o sistema operacional Sunos da
Sun, que talvez tenha sido o último grande Unix com característica somente de
BSD ou SYS V. A partir daí, com o Solaris da mesma Sun, na década de 90, e o AIX
da IBM, houve uma tendência de sedimentar no mesmo sistema operacional o
que havia de melhor nos dois ambientes.
Diversas versões reduzidas do Unix também foram desenvolvidas para uso em
sala de aula, sendo a versão mais conhecida denominada de Minix, escrita por A.S.
Tanenbaum, que serviu posteriormente como base do sistema operacional Linux
– um Unix para arquitetura X86, originalmente, e hoje multiplataforma.
UNIX EM IBM PC
Unix é um sistema multiusuário e multitarefa e necessita de um hardware mí-

nimo para executar o requisito principal de suporte à proteção de memória, na
unidade de gerência de memória (MMU) do computador. O hardware do IBM PC
só passou a fornecer suporte à proteção de memória de forma adequada no pro-
cessador Intel 386, o que levou o desenvolvimento de versões estáveis do Unix
para IBM PC.
Diversas versões de Unix foram construídas para IBM PC, em especial o sistema
XENIX pela Microsoft, adquirido depois pela Santa Cruz Operation e denominado
SCO Unix, uma versão do Unix da AT&T na sua versão 7. Diversas implementações
baseadas no BSD Unix foram feitas no hardware do IBM PC, em especial o NetBSD,
FreeBSD e OpenBSD.
58
O Linux, sistema comum atualmente, teve sua origem indiretamente do Unix, e

foi baseado no sistema operacional Minix, uma versão acadêmica reduzida do Unix.
Neste tópico, você conheceu a origem do Unix e a sua importância enquanto
sistema operacional multiplataforma e primeiro sistema operacional escrito em
uma linguagem de alto nível. Você percebeu que hoje não precisamos mais de
um sistema operacional para cada hardware, pois nossos sistemas são multiusu-
ários e multitarefas.
2.1.11 IBM PC E SEUS SISTEMAS OPERACIONAIS: DO MS DOS AO

WINDOWS 7
Você deve estar se perguntando por que o sistema operacional Unix não foi
implementado como primeira opção IBM PC, já que era multiplataforma e de có-
digo aberto em sua versão BSD Unix. Qual a razão de se usar o MS DOS?
Tem algumas questões sobre a história dos sistemas operacionais que você
deve saber!
a) O MS DOS, primeiro sistema operacional para microcomputadores IBM PC,
não foi desenvolvido pela Microsoft, mas comprado no mercado por 50 mil
dólares. Ele era uma variante de um sistema operacional chamado CP/M, do
Unix.
b) Os sistemas de janela foi desenvolvido na Xerox e implementado depois
nos computadores da Apple, e somente muito mais tarde implementado
nos PCs.
c) O Windows não era a primeira opção para interface gráfica no PC. A IBM
apostava em outro produto: o OS/2.
Conheceremos um pouco da história de um homem visionário, o Steve Jobs,
e de um homem de negócios, o Bill Gates, e de duas empresas sem percepção da
evolução da informática: a Xerox e a IBM. Essas histórias nos ajudarão a entender
que caminhos nos levaram a produtos como o Windows Me ou ao Windows Seven.
DA ORIGEM DA MICROINFORMÁTICA
Na década de 70, os sistemas existentes eram mainframes e minicomputado-

res. Com o lançamento do microprocessador de uso geral pela Intel, em 1972,
seguido por outras empresas como Motorola e Zilog, surge um mercado focado
em desenvolvimento de pequenos computadores: os microcomputadores.
59
Esse mercado surgiu, em um primeiro momento, no meio de “hobistas”, que

se encontravam em clubes de informática para trocar projetos de sistemas com-
putacionais. Apareceu também por meio de revistas de eletrônica, que traziam
como encarte o diagrama de uma placa eletrônica que o “hobista” podia fabricar
e, em outros números trazia os diversos componentes encartados ou a lista de
onde eles poderiam ser encontrados para comprar. O interessado juntava o dia-
grama da placa, fabricava e soldava os diversos componentes na placa. Arrumava
uma caixa e pronto: tinha seu computador – sem software ou sem sistema opera-
cional. O software era digitado e gravado em uma Eprom ou ROM. Era um método
árduo de se ter um computador, você não acha? Imagine um leigo em eletrônica
tentando montar um!
Foi pensando nisso que Steve Jobs (visionário que deu utilidade à informática)
e Wozinak (engenheiro de computação) desenvolveram na garagem da casa de
Jobs um microcomputador que denominaram Apple, sendo a usabilidade a ca-
racterística deste microcomputador (uso e usabilidade marcaram o caminho da
Apple nas décadas seguintes). A visão de Jobs era de que leigos necessitavam de
computadores, então fizeram algo diferente! Ao invés de vender kits eletrônicos,
vendiam o computador montado em uma caixa, com o sistema operacional e sof-
tware de trabalho básico. Era algo novo e, nesta fase, começava a microinformática
em escala. O sucesso foi tal que logo veio a Apple II e o Machintosh. Isso chamou a
atenção da IBM, ao ponto de ela entrar no mercado, mesmo não acreditando nele.
O nome Apple foi dado à empresa de Jobs em menção

VOCÊ à maçã que permitiu Newton instituir a lei da gravidade,
bem como ao hábito americano de consumir maçãs. O
SABIA? Machintosh, máquina de sucesso da Apple, tem o nome
de um tipo de maçã muito consumida.
IBM PERSONAL COMPUTER
A IBM não acreditava no mercado de microcomputadores, mas era pressio-

nada a entrar nesse mercado. A opção foi procurar um parceiro, mas que fosse
diferente no mercado. A Apple usava processadores Motorola, a linha TRS80, bas-
tante comum, o Zilog Z80. A IBM precisava de algo novo. Buscou a Intel que tinha
um novo processador de 16 bits, o Intel 8086, substituto da linha 8080 de onde a
Zilog fez o Z80.
Havia apenas um problema: o 8086 era de 16 bits e encareceria o projeto da
IBM, já que os microcontroladores no mercado eram quase todos de 8 bits. A so-
lução foi a Intel desenvolver uma variante do 8086 de 8 bits, o Intel 8088, que
equiparia a linha de microcomputadores desenvolvida.
60
A IBM não acreditava em manter o projeto em escala e com longa duração,

então fez uma arquitetura aberta que permitia a quem quisesse estender o IBM
PC (Personal Computer). Mesmo a IBM sendo pioneira em informática e tendo
técnicos altamente capacitados para desenvolver um sistema operacional para a
nova máquina, não o fez por acreditar que seria jogar dinheiro fora. A solução era
buscar um produto no mercado. Onde encontrar? Uma empresa criada há pouco
tempo ofereceu à IBM uma solução de sistema operacional para o seu microcom-
putador: a Microsoft (na verdade, a empresa não possuía o sistema operacional
e o adquiriu na Seattle Computer). O sistema seria repassado à IBM sem custos.
Na verdade, havia apenas uma cláusula que dizia que cada máquina que a IBM
vendesse, deveria ser acompanhada de uma cópia desse sistema operacional, o
MS DOS, e o valor repassado à Microsoft. A IBM acreditou ser um bom contrato,
pois não acreditava no IBM PC, o futuro mostrou que estavam errados, pois seu
produto se tornou o padrão de arquitetura para a microinformática.
O MS DOS era baseado no CP/M em termo de organização de acesso a disco
e comando, e internamente baseado no Unix, contudo, devido à fragilidade do
processador 8086, ele era um sistema operacional monousuário e monotarefa.
Isso não era visto como problema para a época, mas o fato de não implementar
proteção nas áreas do sistema operacional permitiu que surgissem os chamados
vírus computacionais.
MICROSOFT WINDOWS
Dado o sucesso do produto IBM PC e a grande vendagem do concorrente di-

reto, o Apple, que no Machintosh trazia uma interface gráfica, bem como o uso
de mouse para acesso ao sistema além de suporte à multimídia, o consórcio IBM/
Microsoft foi pressionado a melhorar seu produto.
A IBM acreditava no desenvolvimento de um sistema multitarefa com interfa-
ce gráfica. A Microsoft acreditava em fazer apenas uma interface gráfica em cima
do MS DOS. Dois parceiros, dois caminhos. A IBM desenvolveu o sistema OS/2,
que obteve relativo sucesso no mercado empresarial, e a Microsoft fez algo que
imitava uma interface gráfica, o Windows da Microsoft. O mercado acabou popu-
larizando por meio da pirataria do Windows, não por ser a melhor solução, mas
devido ao IBM OS/2 exigir um hardware pouco mais robusto.
Diversos sistemas operacionais foram desenvolvidos para o IBM PC, incluindo
uma versão do DOS (Disk Operating System) da IBM, o IBM PCDOS. Existia ainda
um projeto que implementava o DOS de forma aberta, o FreeDOS, usando-o em
alguns ambientes.
Após o desenvolvimento da interface gráfica que rodava em cima do MS DOS,
o Windows, a Microsoft tratou de aprimorar seu produto nas versões 3.0, 3.1,
61
3.1.1, tentando oferecer ao usuário a sensação de multitarefa. Por não proteger o

sistema operacional (mesmo no momento que os processadores dos PCs já ofe-
recessem uma MMU decente, a partir do Intel 386) era imenso o crescimento dos
vírus nesse ambiente, ainda mais quando ligados em rede. O Windows ME, deno-
minado bug do milênio pelos críticos, foi o fim do ciclo, estava claro que o sistema
operacional deveria ser reescrito.
O WINDOWS NEW TECHNOLOGY
O caminho para reconstruir o sistema operacional da Microsoft tinha come-

çado alguns anos antes. Visando a fornecer um servidor de redes e competir no
mercado com a empresa Novell, com seu netware, a Microsoft focou em desen-
volver um novo sistema que foi conhecido como Windows NT (New Technology),
um sistema operacional baseado em microkernel, com suporte à multitarefa e
multiusuário e com características baseadas no Sunos da Sun para o suporte à
rede. O Windows NT, em seu núcleo versão 5, foi a base da versão seguinte: o
Windows XP, líder em desktops, lançado em 2001. As versões seguintes do siste-
ma operacional, chamados de Vista e, atualmente de 7(Seven), trouxeram poucas
evoluções em relação ao Windows XP, que já era um sistema estável, mas que não
apresenta a graça, leveza e usabilidade do MAC OS, o sistema da Apple.
Com a melhoria do hardware no início dos anos 90, a Sun propôs adequar seu
sistema Unix, o SunOS, em multiplataforma, levando a uma implementação para
plataforma IBM PC. O SunOS foi reescrito totalmente e recebeu o nome Solaris, po-
dendo ser executado tanto em plataforma SPARC Sun, como IBM PC (X86). O Unix
BSD também foi portado para o hardware do PC, executando de forma adequada.
Você aprendeu, neste tópico, os caminhos que foram tomados para chegar ao
Windows 7 como sistema operacional no IBM PC e a razão de não se ter o Unix,
por exemplo, como padrão nesse hardware. Contudo, a evolução do hardware
permitiria a execução do Unix no IBM PC, tanto que o Linux se consolidou como
um produto.
62
2.1.12 ADVENTO DO LINUX

10 API
Application Programming
Interface (ou Interface
de Programação de
Aplicativos) é um conjunto
de rotinas e padrões
estabelecidos por um
software para a utilização
das suas funcionalidades
por aplicativos que não
pretendem envolver-se em
detalhes da implementação
do software, mas apenas
usar seus serviços.
Figura 32 - Linux
Certamente você já ouviu falar que o Linux é um sistema operacional revolu-

cionário, que está tomando o mercado, algo totalmente novo. Bom, na verdade
é apenas mais uma variante do Unix, mas com um grande apelo de marketing
e apoio da indústria. Vamos estudar um pouco sobre este sistema operacional,
conhecer sua história e conceitos?
UM POUCO DE HISTÓRIA
A evolução dos sistemas operacionais é marcada pela tentativa de termos uma

API10 padronizada para cada um deles, em que o desenvolvedor pudesse aperfeiço-
ar sua aplicação sem pensar onde iria executar, qual seria o hardware. Dessa forma,
o sistema operacional deveria prover a noção de um hardware universal. Ao longo
do tempo foram se distanciando dos demais sistemas e provendo APIs totalmente
diferentes, levando à necessidade de um especialista para cada um. A evolução do
hardware levava à evolução dos sistemas operacionais em um ciclo vicioso.
Mesmo o Unix não conseguiu se manter sozinho, entre suas várias implemen-
tações, uma interface padrão, necessitando elaborar um documento que estabe-
lecesse esta API padrão, denominado POSIX (Portable Operating System Interface
for Unix - Interface portável de sistema operacional para Unix).
Quando foi lançado o IBM PC, não oferecia requisitos de hardware para supor-
tar um sistema operacional multitarefa, muito menos multiusuário, nem era o ob-
jetivo deste hardware. Com a introdução do processador Intel 386, já foi possível
implementar um sistema operacional decente. Qual poderia ser?
Uma resposta poderia ser o Unix devido à sua grande variedade de portes.
Bom, qual o Unix, o AT&T ou BSD?
A resposta parece óbvia: devido ao código fonte disponível seria o BSD Unix. E
assim o foi. No início da década de 1990, havia diversos portes do BSD Unix para
o IBM PC em especial 386BSD, que deu origem aos NETBSD, OpenBSD e FREEBSD.
63
O INÍCIO
Em 1992, a internet foi aberta à comunidade não científica. A ideia era cola-
borar em nível de uma grande “aldeia global”. Tornava-se realidade a descrição
feita por Mashall McLuhan na década de 60, na qual afirmava que “a nova interde-
pendência eletrônica recria o mundo à imagem de uma aldeia global” (00080). As
possibilidades de colaboração em escala mundial nunca tinham sido tão presen-
tes, a introdução do acesso hipermídia a ela via navegadores e web, tornou isso
realidade para pessoas que não tinham experiência em informática.
Na Finlândia, em 1989, um estudante de graduação chamado Linus Torvalds se
deparava com um problema: gostaria de ter um sistema operacional melhor em
seu computador do que os da Microsoft, mas não vislumbrava nenhum (se tivesse
pesquisado um pouco mais, teria encontrado uma vasta lista de sistemas Unix BSD
que resolveriam seu problema). Teve, então, a ideia de pegar o código fonte Minix
que tinha usado em uma disciplina de graduação e melhorá-lo para que pudesse
usar em seu computador. Começou a tarefa de voltar às coisas que haviam sido
removidas do Unix no Minix e logo postou uma versão do núcleo do sistema na
internet, pedindo colaboração no seu desenvolvimento, como prática da época.
Outros acharam interessante e começaram a colaborar e divulgar a ideia.
Marcio Pessoa
Figura 33 - Linus Torvalds
O Minix é um dos muitos sistemas operacionais simplificados que foram de-

senvolvidos baseados no Unix para fins de ensino. Foi desenvolvido por A.S. Ta-
nenbaum.
64
O GNU LINUX
Denis Pacher
Figura 34 - Logo GNU
Fonte: gnu.org
Um ponto importante que precisa ser mencionando é que um sistema opera-

cional não é apenas um núcleo, mas também as bibliotecas de acesso, as shells,
os compiladores de linguagem, a interface gráfica, os editores de textos, dentre
outros. Primeiramente, estavam trabalhando apenas no sistema operacional que
recebeu o nome de Linux em um trocadilho com o nome de seu organizador,
Linus Torvalds e Unix.
Para usar o Linux, nesta primeira fase, devíamos baixar o sistema operacional
da internet e as diversas ferramentas de outros sites, juntar tudo e usar. Parecia e
era muito complicado fazer isso.
Logo, uma grande gama de ferramentas que vinham sendo desenvolvidas no
projeto GNU de software livre ao longo do tempo se juntou ao projeto Linux e
adotou-se nome GNU/Linux.
AS DISTRIBUIÇÕES
A partir dessa união, surgiu a ideia de juntar todos os componentes que eram
necessários para que o sistema operacional executasse em um único lugar e de-
pois distribuí-los já agrupados.
Uma distribuição Linux consistia, e consiste, em um conjunto de ferramentas
selecionadas para fazer o kernel Linux funcionar em um sistema completo. A pri-
meira distribuição Linux foi a SLS e depois vieram as distribuições Slackware, De-
bian e Red Hat, nas quais quase todas as demais são baseadas.
Uma distribuição se difere da outra por uma série de razões:
a) Uso: se é para um servidor, para um desktop, para um embarcado;
65
b) Conjunto de ferramentas: escolha de conjunto de compiladores, editores,

ferramentas de produtividade, navegadores;
c) Forma de administrar: o BSD Unix sempre manteve os arquivos de adminis-
tração no diretório /etc/rc.d o AT&T no /etc/init.d.;
d) Uma distribuição Linux é um kernel Linux e um monte de ferramentas, nas
quais fica a critério do usuário decidir onde será feita a administração. Ti-
vemos decisões sensatas como a do Slackware Linux que mantém a linha
BSD UNIX de administração e outros o SUSE que mantém a administração
no diretório /usr.
De forma a trabalhar com diversas distribuições Linux, um consórcio montou
o Linux Standard Base (LSB) que diz onde os arquivos de administração devem
estar, recomendando uma distribuição, mas não é obrigatória.
SAIBA Uma linha do tempo com as diversas derivações do Linux

MAIS pode ser vista em <http://futurist.se/gldt/>
Lembre-se de que no Linux o componente mais importante é o Kernel, e suas

distribuições são apenas a cobertura do bolo, se assim podemos dizer. No merca-
do são comuns termos “especialistas” em distribuição A ou B. Tente fugir dessas
abordagens, se você conhece como o sistema Linux funciona, saberá usar qual-
quer distribuição.
AS RAZÕES DO SUCESSO
Dreamstime
Figura 35 - Sucesso
66
Podemos destacar uma série de outros fatores, além do embasamento no

Unix, um sistema tradicional, mas a internet foi o principal. Devido ao desenvol-
vimento do TCP/IP integrado no Unix era natural de se esperar que os servidores
para web, e-mail e outras aplicações fossem baseados em Unix.
A internet estava explodindo no início da década de 1990 e as estações de
trabalho baseadas em processadores RISC tinham um alto custo, enquanto um
PC custava em torno de mil dólares, uma estação RISC custava em torno de 10
a 20 mil dólares. Em virtude do alto custo, o uso do Linux se popularizou como
servidor para a internet, mesmo que em seu primeiro Kernel não fosse muito es-
tável. Junto ao Linux, surgiram outras tecnologias, como o servidor HTTP Apache,
a linguagem PHP, o banco de dados MYSQL, e os serviços de nome, DNS, e DHCP
da ISC, todos líderes e padrões no mercado ainda hoje.
A tecnologia LAMP é uma sigla para Linux, Apache, Mysql e PHP, tecnologias
bastante usadas juntas na web.
Em 1996, a Novell e a Microsoft ainda não acreditavam no sucesso da internet.
Hoje a Microsoft possui um sistema operacional para servidores estáveis baseado
no núcleo NT, mas isso é apenas um detalhe, visto que o mercado experimentou,
aprovou o Linux e outras variantes do Unix com absoluto sucesso. Diversas em-
presas líderes de mercado têm mantido esse apoio ao sistema operacional, como
IBM, Oracle e HP, dentre outras.
No mercado de desktop, entretanto, ainda se mantém como padrão o Micro-
soft Windows, apesar dos esforços da comunidade Linux e da excelente qualida-
de do MAC OS X.
Mas um produto baseado em Linux tem chamado bastante a atenção: o An-
droid da Google. A Google tem fomentado dois sistemas operacionais: o Android
para tablets e celulares e o ChromeOS para nuvem computacional, ambos basea-
dos no Linux/Unix.
Agora você pode dizer que conhece o Linux, sistema derivado do Unix, que se
impôs no mercado pelo seu baixo custo, modelo de desenvolvimento e qualida-
de, bem como o apoio de grandes empresas.
2.1.13 ESTADO ATUAL
Neste tópico, falaremos sobre um pouco de mudanças e para onde os ventos

da inovação levam os sistemas operacionais. Para entendermos qual é o estado
atual dos sistemas operacionais, é necessário sabermos quais são as tendências
para este mercado. Vamos começar entendendo um pouco dessas mudanças?
67
O MUNDO MUDA - TENDÊNCIAS
Dreamstime
Figura 36 - Tendências
No início era o mainframe, o melhoraram e o tornaram multitarefa. A IBM apa-

receu com a ideia de virtualização de hardware e, na década de 70, surgiram os
minicomputadores e o Unix, escrito em linguagem de alto nível, multiplataforma
– a “caixa de pandora” estava aberta e poderiam desenvolver o sistema operacio-
nal enquanto abstração de alto nível, separado do hardware.
Diversos caminhos surgiram e cada vez mais processamento: a máquina para-
lela que permitia uma execução de tarefas mais rápida que o campeão mundial
de xadrez era um computador: o IBM Deep Blue. As máquinas paralelas cresce-
ram, foram ligadas em redes, viraram clusters, grid. E o Unix sempre presente!
Que o campeão mundial de xadrez, Garry Kasparov, jo-

gou com Deep Blue (1956), o supercomputador criado
VOCÊ pela IBM para jogar xadrez, e perdeu de 4 a 2? Em 1997,
SABIA? repetiram o jogo e o Deep Blue ganhou novamente,
sendo o primeiro computador a ganhar de um campeão
mundial.
De outro lado, o simples. A mesa, IBM PC, simples, por sua arquitetura aberta,
cresceu. Hoje possui processadores com vários núcleos e/ou com várias linhas de
execução (threads). Tanto poder de processamento em uma mesa que a usamos
de forma mais adequada, via virtualização ou paralelismo.
68
Juntando a isso veio a internet ligando a tudo e a todos. A mobilidade via Wifi
ou 3G/4G. O Ipod da Apple foi um passo. Sempre presente, sempre conectado. As
aplicações cresceram, os usuários mudaram também.
Surge um espantoso mundo. A computação em nuvem e como serviço. Nada
muda, na verdade voltamos ao paradigma do mainframe, a diferença é que esta-
mos em uma plataforma aberta de hardware e Unix.
O sistema operacional, diante do novo modelo de computação, tende a mu-
dar constantemente com estas e outras novidades na informática. Estamos na era
pós-PC, onde frequentemente usamos dispositivos embarcados, como celulares,
TV digital ou tablets.
Curiosamente, do outro lado, quando pensamos no IBM PC, vimos que alcan-
çou um nível de maturidade muito alto em sua arquitetura, suportando múltiplos
processadores e múltiplos núcleos em cada CPU.
Os sistemas operacionais têm que atender os dois mundos. Do ponto de vista
de embarcados, a necessidade é cada vez mais fazer o simples: hardware simples
e diminuto. Aqui temos o IOS da Apple como referência, junto ao Android da
Google, duas variantes Unix. Para que os principais sejam citados, temos ainda
o Microsoft Windows Mobile. Se a tendência é termos embarcados, esses são os
sistemas operacionais.
No caso da computação em nuvem, o sistema operacional na máquina pode
ser simples, sendo basicamente o núcleo, um mecanismo de autenticação e um
browser para acessar os serviços. É uma tendência na forma de netbooks e tablets,
com destaque ao Chrome OS e ao Android.
Se pensarmos no desktop e no servidor, os processadores têm mais núcleos e
capacidade de processamento. Sistemas operacionais que suportem essas carac-
terísticas, bem como o suporte à virtualização de hardware em ambiente multi-
core (multinúcleo), são a tendência. O Unix, em suas variantes Linux, OpenBSD e
FreeBSD, e MAC OS X tem destaque aqui.
Do ponto de vista interno dos sistemas operacionais, a presença de diversos
núcleos tem levado ao uso massivo de virtualização de hardware, com suporte
pelos principais fornecedores de processadores de mercado – Intel e AMD. A mu-
dança do sistema operacional para suportar muitos núcleos de forma mais ade-
quada, com alteração do módulo de gerência de processos e memória, tem sido
muito interessante.
O aparecimento de novos hardwares, como de armazenamento em estado só-
lido em discos SSD (Solid State Disk), tem levado à nova forma de tratar sistemas
de arquivos, em que o paradigma passa a ser endereçar partes de memória física,
formando arquivos no lugar de setores em discos rígidos.
69
O suporte à computação em rede também tem evoluído. Como destaque te-

mos a plataforma Java, que permite implementar portabilidade de aplicações.
Com o uso de Java, o software executa em uma máquina virtual isolado do siste-
ma operacional e do hardware. Nesse caso, a otimização dá prioridade a melho-
rias às JVMs (Java Virtual Machine) para cada sistema operacional diferente.
No âmbito de novos periféricos, o uso de telas sensíveis ao toque e contro-
le sem fio, como o Kinect da Microsoft, tem mudado a forma que interagirmos
com os sistemas operacionais. Isso traz mudanças no seu funcionamento – esses
periféricos necessitam de mais atenção em tempo real. São feitas mudanças no
suporte a drivers de dispositivos, mas até o escalonamento é afetado.
Atualmente temos que nos adaptar às mudanças na forma de trabalhar com a
informática – isso gera efeito imediato nas aplicações e, se desejarmos, um bom
desempenho no sistema operacional. Nossa meta é entender os conceitos bási-
cos desses sistemas, que têm se mantido constantes nas últimas décadas, deixan-
do um pouco de lado a tecnologia que muda a cada semestre.
Com as constantes modificações trazidas com as tecnologias, você deve ter
percebido que o modo que usamos a informática altera aceleradamente. Com
esta constatação, fica claro que o investimento no melhoramento dos sistemas
operacionais e no desenvolvimento de novos recursos é imprescindível. Fique
atento às mudanças, às novas aplicações, ao funcionamento dos sistemas para
que consiga acompanhar as novas formas de se trabalhar com a informática.
2.2 VIRTUALIZAÇÃO
2.2.1 COMPILAÇÃO E INTERPRETAÇÃO
Normalmente trabalhamos com linguagens de alto nível como C ou Java para

o desenvolvimento de software. Você já pensou como um programa em determi-
nada linguagem de programação se transforma em um programa executável que
o computador possa rodar?
DESENVOLVIMENTO EM BAIXO NÍVEL
Os primeiros computadores eram grandes arranjos de circuitos combinacio-

nais em que o software executava diretamente. Os programas eram escritos em
código de máquina que eram executados por ela diretamente sem fazer uso de
microprogramação ou outra estratégia. As instruções eram representadas por
número que eram processados como comandos e dados pelo sistema computa-
70
cional. Como forma de simplificar a escrita deste código, passou-se a usar cono-
tação binária (cada bit podia representar um estado lógico), octal (suficiente para
exprimir dados de 7 bits) e posteriormente em hexadecimal (0 a 255 podem ser
representados por duas letras 00 a FF).
Dada a dificuldade de se escrever uma ideia utilizando apenas números, seja
binários ou hexadecimais, foi desenvolvida a linguagem Assembly (ou linguagem
de montagem). No Assembly o programa é escrito em mnemônicos, sendo que
cada mnemônicos tem uma tradução direta para o código de máquina do har-
dware. Um exemplo: se queremos guardar o valor 10, poderíamos ter os códigos
mostrados na tabela.
Tabela 1 - Representação em diversas linguagens de uma atribuição
Instruções Linguagem
A <- 10 pseudocódigo
A=10; linguagem C
Mov AX,10 usar o registrador AX para armazenar o valor 10
10E200A código de máquina em hexadecimal (código hipotético a título de exemplo)
Fonte: Autor
Ao observarmos a tabela vemos que:

a) primeira linha é facilmente entendida como uma atribuição;
b) segunda linha faz uso da semântica de matemática para representar a atri-
buição;
c) terceira linha demanda conhecer o hardware onde a atribuição será feita,
neste caso no registrador Ax da CPU;
d) última linha é o código que o processador executará. Quanto mais próximo
do hardware (linguagem de máquina), mais difícil para nós entendermos um
código.
O MONTADOR OU ASSEMBLER
O software que faz a tradução da linguagem Assembly para o código de má-

quina é chamado de montador ou Assembler. No processo de montagem todo
o código escrito em Assembly é lido de um arquivo, traduzido para o código de
máquina e armazenado em outro arquivo, e aí pode ser executado. O armaze-
namento do arquivo contendo o código traduzido em um arquivo denominado
programa executável nos permite realizar o processo de tradução apenas uma
vez economizando tempo de processamento.
71
Um programa escrito em linguagem de máquina ou Assembly é chamado de

programa de baixo nível, por executar diretamente no hardware, nesse caso após
a tradução. .
A LINGUAGEM DE ALTO NÍVEL - COMPILADOR
Dadas as especificidades das linguagens de máquinas e seus Assemblys, que

são diferentes para cada hardware, ao longo do tempo foram desenvolvidas lin-
guagem chamadas de alto nível, em que no processo de tradução cada comando
nessa linguagem pode ser traduzido em dezenas de comandos da linguagem de
máquina. Um programa em C, por exemplo, é traduzido para Assembly e depois
para o código de máquina. O software que faz essa tarefa é conhecido por com-
pilador. Um exemplo:
Tabela 2 - Código em C e em Assembly
Código C Assembly
mov ax,[a]
mov bx,[b]
cmp ax,bx
if (a > b) jg then
a=10; mov [a],20
else a=20; jmp cont
then:
mov [a],10
cont:
Fonte: Autor
O código na primeira coluna da tabela seria traduzido para algo próximo da

segunda coluna (foram colocadas apenas as instruções chaves, com o mesmo pa-
drão de cores nas duas colunas) e daí para o código de máquina.
Em um processo de desenvolvimento de software, se você escreve seu código
em uma linguagem de alto nível como a C, mas o computador executa apenas
código de máquina, podemos dizer que os programadores vivem em uma ca-
mada virtual do hardware, já que não necessita conhecer os detalhes do mundo
real, mas apenas da linguagem C, pois o compilador e o montador escondem o
processo. Temos um exemplo de virtualização.
72
A INTERPRETAÇÃO
E se você quiser escrever o código em alto nível e executar o mesmo de ime-

diato, uma vez somente, o processo de compilação e montagem não seriam len-
tos em demasia gerando um arquivo de saída executável que seria usado apenas
uma vez? Não existiria uma alternativa?
Uma alternativa para o mecanismo de compilação e montagem descrito con-
siste na interpretação, tendo como exemplo a linguagem Basic.
Em uma linguagem interpretada construímos um software, o interpretador,
que para cada comando da linguagem criado, executa uma ação invocando um
método ou chamando uma função. Apenas o interpretador foi compilado para as
instruções de máquina e executa sobre o hardware, todo software que escreve-
mos, em Basic, por exemplo, não executa diretamente.
Vamos a um exemplo em alto nível: se você precisasse conversar com amigos
que falam espanhol, português, mandarim, alemão, e conhece apenas o Portu-
guês. Como fazer?
Como você fala português poderá interagir com amigos que falam português
diretamente. Podemos associar este comportamento à noção de linguagem de
máquina: falo a língua local.
Nos demais casos, pensaríamos em:
a) Opção 1: aprender todas as linguagens, mas pode ser complicado e demo-
rado.
b) Opção 2: ter alguém que fale português/espanhol, português/mandarim,
português/alemão e se desejo falar com um amigo chinês posso falar em
português com a pessoa que fala português/mandarim e ela intermediará a
conversação, temos o papel de um intérprete, como exemplo de um inter-
pretador.
Um interpretador funciona com uma camada sobre o hardware, a cada coman-
do de alto nível é traduzida para comandos de baixo nível. Semelhante à figura
abaixo:
73
Processamento
Interpretador
Denis Pacher (2012)

Hardware-Processador
Figura 37 - Interpretador
Como vantagens do compilador, temos código disponível para ser executa-

do como um todo, e podemos tentar otimizá-lo em tempo ou tamanho, mas se
quisermos executá-lo em diversos hardwares, o código deverá ser recompilado.
O interpretador tem a vantagem da simplicidade, compilamos o interpretador
para as plataformas que desejamos, e a partir dai nosso código na linguagem
interpretada pode ser usado em qualquer máquina onde ele esteja disponível. A
desvantagem é que esta abordagem é muito mais lenta, visto que a tradução de
instruções do virtual para o real (código de máquina que a CPU executar) pode ser
feita em tempo de execução e toda vez que uma mesma instrução for executada
terá que ser traduzida novamente.
Se avaliarmos do ponto de vista que o sistema operacional também se apre-
senta como camada sobre o hardware, em que o acessamos para chegar ao sof-
tware, temos um caso de virtualização da mesma forma. Nos primeiros microcom-
putadores, era comum o desenvolvedor colocar na BIOS do microcomputador
um interpretador para a linguagem de programação Basic, de forma tal que a
máquina já ligava e carregava o interpretador para o usuário digitar seu código e
usar. Foi uma abordagem bastante comum, atualmente quando queremos usar
um compilador o fazemos sobre o sistema operacional.
Discutimos, neste tópico, os princípios de funcionamento e uso dos sistemas
computacionais muito importantes: a interpretação e compilação. Estes permi-
tem aos desenvolvedores de código não conhecer o hardware que estão usan-
do. Trabalhamos em um nível virtual, uma abstração de hardware. Aliando estas
técnicas de desenvolvimento aos conceitos de sistemas operacionais modernos
temos nosso ambiente de informática de hoje.
74
2.2.2 Java Virtual Machine – JVM
Figura 38 - Java
Você já pensou se um software pudesse ser executado em qualquer computa-

dor e em qualquer lugar? Seria legal, concorda? A Sun Microssystems apresentou
uma solução para o problema de portabilidade que dominava o mercado de sof-
tware: a JAVA. Vamos discuti-la neste tópico?
PRIMÓRDIOS DE JAVA
Em 1979, com a popularização das redes de computadores a ISO e ITU-T co-

meçaram a trabalhar em um modelo de referência (RM) que permitisse a conexão
de equipamentos de diversos fornecedores, o chamado RM-OSI (Open Systems
Interconnection - Interconexão de sistemas abertos) que ficou pronto em 1985. No
RM-OSI existia a preocupação com aplicações que executassem em equipamen-
tos diferentes conectados via rede, isso pode ser notado na camada 5 (seção), 6
(apresentação) e 7 (aplicação), mas o suporte era muito simples. Em 1989, a ISO
notou que crescia a demanda por escrita de código que executasse de forma dis-
tribuída na rede, diversas soluções proprietárias surgiam no mercado, um padrão
de referência era necessário.
Redes de computadores proveram uma abstração de mecanismo de comuni-
cação, mas não de desenvolvimento de software. A ISO e ITU-T iniciaram, então,
a padronização da denominada RM-ODP (Reference Model for Open Distributed
Processing). No RM-ODP foi definida a forma que se daria suporte ao desenvolvi-
mento de aplicações que seriam baseadas em objetos que eram executados co-
laborativamente na rede. Um quesito pensado no RM-ODP foi o de migração de
um objeto em execução, ou seja, uma aplicação executando em um computador
com processador e sistema operacional X migrar para outra máquina com har-
dware e sistema operacional, mantendo sua execução. A proposta feita foi de se
ter um código universal que rodasse em qualquer máquina, isso implica a existên-
75
cia de uma máquina virtual (interpretador). A tecnologia Java da Sun é baseada

nos conceitos do RM-ODP de portabilidade de código e encapsulamento.
CARACTERÍSTICAS
Java consiste em uma linguagem baseada em C++, variante orientada a obje-

tos da linguagem C, que apresenta um diferencial. Código fonte Java não é com-
pilado para o código de máquina do hardware onde vai executar, mas sim para
um código de máquina executável (byte code) em um interpretador conhecido
como Java Virtual Machine (JVM). Para permitir a execução de código Java, ne-
cessitamos ter um JVM instalado na máquina e sobre ele o interpretador executa-
rá o código Java, isto pode ser observado na figura abaixo.
Aplicação Java - Objetos
Java Virtual Machine - JVM
Sistema Operacional
Denis Pacher
Hardware
Figura 39 - Java
Se desejarmos migrar a aplicação para um novo hardware, não necessitamos

recompilar ou alterá-la, basta termos uma JVM no novo hardware que o software
compilado para este formato intermediário Java, conhecido como byte code, será
executado na nova plataforma. Hoje, mais de 80% dos softwares sendo desenvol-
vido para fins gerais estão sendo feitos em Java. Uma parcela do desenvolvimen-
to é feito em C#, uma implementação proprietária de Java da Microsoft.
Salientamos que as aplicações não interagem mais com o sistema operacional,
mas somente com a JVM. O que necessita interagir com os sistemas operacionais
locais é a JVM, como na figura abaixo.
76
Apps Apps Apps
JVM JVM JVM
Linux Windows Android
Denis Pacher
Hardware Hardware Hardware
Figura 40 - Modelo de interação Java
Podemos notar que para a aplicação o hardware não muda. Podemos trocar
o hardware, o sistema operacional e a aplicação continuarão a executar sem pro-
blemas, garantido sua portabilidade desde que tenhamos uma máquina virtual
Java (JVM).
Um ponto chave em relação à Java consiste no desempenho. Por ser uma lin-
guagem interpretada, cada comando tem de ser traduzido em tempo de execu-
ção do byte code Java para o código de máquina real e executado, uma forma de
minimizar isto foi a Sun introduzir o JIT (just in time compiler) que traduz ao car-
regar o objeto para memória, os trechos chaves para o código de máquina local.
É uma tentativa de melhorar o desempenho, mas dificilmente conseguiremos a
velocidade e uso de recursos de uma linguagem compilada, contudo, estamos
abrindo mão de velocidade em nome de portabilidade.
O uso deste hardware “abstrato” da JVM nos permite separar o sistema ope-
racional e o hardware real, trabalhando em um mudo virtual. Você deve estar se
questionando: portabilidade não era o que desejávamos com um sistema opera-
cional desde a década de 50? Sim! Do ponto de vista prático não necessitamos
mais um programador especializado em cada sistema, basta saber desenvolver
para o ambiente Java e deixar o pessoal de suporte instalar as máquinas Java e
pronto. A popularização foi tal que temos JVMs para quase tudo, desde computa-
dores a celulares, videogames e mesmo para computação embarcada.
Vimos que a solução Java da Sun permitiu a realização de um antigo sonho em
computação: o desenvolvimento de código portável. Mas tudo tem seu preço,
neste caso a queda de desempenho.
2.2.3 VIRTUALIZAÇÃO DE HARDWARE: DEFINIÇÃO E HISTÓRICO
Se refletirmos sobre um desenvolvedor de software, ele vive em um mundo

virtual implementado pelas linguagens de alto nível, isolando-se da linguagem
de máquina no desenvolvimento do software, bem como virtualização que a Java
77
nos fornece. Vamos entender, neste tópico, a implementação da virtualização

no hardware.
HISTÓRICO
Quando conseguimos melhorar os primeiros computadores, foi possível sua

venda enquanto produto comercial, mesmo que em pequena escala, mas que
devido ao alto custo surgiu a necessidade de compartilhar seu uso. O alto custo
dos equipamentos levou a criação de ideias que permitissem o uso máximo da
CPU, soluções como multitarefa e tempo compartilhado foram criadas.
Os sistemas multitarefa/multiusuários permitiam isolar relativamente diversas
aplicações que executavam em um computador. A CPU quase sempre tinha seu
tempo de uso disputado arduamente e o mecanismo de I/O era o gargalo. Na
década de 70, surgiram máquinas menores, mas seguiam a mesma lógica de uso.
Na década de 80 com os microcomputadores, o cenário mudou. A CPU era tão
frágil que os primeiros sistemas operacionais implementados foram monotarefa.
A EVOLUÇÃO DOS PROCESSADORES INTEL
Do Intel 8086 original, passado pelo 8088 incorporado no IBM PC original, até
os processadores atuais existiu uma longa evolução. Com o tempo o desenvol-
vimento de processadores mais rápidos e eficazes levou a um problema inte-
ressante, que se consolidou no processador Pentium 4 da Intel: a velocidade do
processador era tal (acima de 3 GHz= 3000Mhz) que as memórias (em torno de
266 MHz) e dispositivos de armazenamento (em torno de 100 Mbps) que a Intel
resolveu implementar o conceito de Hyper Threading (existia apenas um proces-
sador, mas ele era mostrado ao usuário como se fosse mais de um, visto seu alto
desempenho, muito maior que os demais componentes do mercado presentes
no microcomputador). Internamente na CPU se via um mecanismo parecido com
o adotado para múltiplos processadores e os programas viam duas CPUs.
Quando o processador Pentium 4 teve que ser removido do mercado devido
à instabilidade, a Intel, que tinha uma CPU de 3,6 GHz, resolveu adotar um produ-
to interno voltado a notebooks como solução, o Pentium M que trabalhava a 1,6
GHz. A solução para não impactar o desempenho foi colocar em um mesmo blo-
co de silício dois processadores Pentium M e programar um circuito de distribui-
ção de carga entre eles. Para o usuário final, quando usava Hyper Thearding exis-
tiam dois processadores de 1,8 GHz lógicos (no Pentium 4 de 3,6 GHz), agora na
solução adotada, chamada de arquitetura Core Duo, existiam dois processadores
físicos de 1,6 GHz que juntos tinham um desempenho bruto próximo ao Pentium
78
4 removido do mercado. O poder de processamento estava aumentando muito,

11 Instanciação visto termos mais de um processor em um microcomputador. Antes esse tipo de
É um processo por meio
característica, devido ao alto custo, era exclusivo de servidores ou estações de
do qual se realiza a cópia alto desempenho para processamento científico ou gráfico.
de um objeto (classe)
existente. Uma classe, Hoje em dia temos processadores com 1, 2, 3, 4, 8 e até 32 núcleos (ou seja,
a qual tem a função de
determinar um tipo de processadores físicos interligados dentro de uma mesma pastilha de silício). En-
dado, deve ser instanciada
para que possamos utilizá-
tão, será que estamos ganhando em processamentos maiores? Nosso software
la. executará mais rápido? Nem sempre. Vamos entender qual a razão.
NOSSAS APLICAÇÕES
Nossas aplicações são desenvolvidas usando a teoria da máquina de Von Neu-

mann, com apenas uma linha de execução: o processador. Para tirar proveito de
vários processadores numa máquina, devemos ter uma aplicação desenvolvida
para a computação paralela, ou uma aplicação distribuída. Grande parte de nos-
sas aplicações não são assim, logo ter uma máquina com 2 núcleos ou 4 núcleos,
comum nos equipamentos atuais, muda pouco o desempenho de um software
em particular. O que fazer?
Diversas soluções foram pensadas, veja a seguir.
a) Não fazer nada: as aplicações se ajeitam. Assim, um editor de texto, antiví-
rus, navegador, podem cada um usar um núcleo de CPU e o sistema opera-
cional cuidar disto. O problema é que uma tarefa por estar usando 100% de
um núcleo em uma máquina Quad Core e os outros três núcleos estarem a
10 % de uso, ou sem uso.
b) Paralelizar as aplicações: seria o ideal, mas aplicações nem sempre podem
ser paralelizadas. Aplicações paralelas implicam divisão dos dados em par-
tes, de tal forma que cada máquina execute uma parcela da atividade de
modo concorrente (paralelo) com as demais. .
c) Virtualizar: virtualizar??? Veremos a seguir...
VIRTUALIZAR
Qual é o significado de virtual, no nosso contexto? O significa virtual?

Virtual é algo que não existe, mas que é a nós apresentado como uma realida-
de, mas no fundo não passa de truque para implementar esta realidade.
Um exemplo de virtual, em nosso contexto, poderia ser a abstração de multi-
tarefa. Quando usamos um computador com determinado sistema operacional e
estamos com antivírus, editor de texto e navegador internet aberto, para nós, to-
79
dos estão executando ao mesmo tempo, mas já sabemos que estão sendo escalo-
nados no tempo. Cada aplicação pega um pouco dos recursos das máquinas, por
exemplo, tempo de CPU. Interessante é podermos usar isso a nosso favor quando
temos excesso de recursos, como no caso de processadores com vários núcleos.
A ideia de virtualizacão de hardware consiste na instalação de uma aplicação
sobre o hardware, a mesma o particiona, alocando partes dos recursos a tarefas
em execução, sendo que cada tarefa é um sistema operacional. O sistema opera-
cional “pensa” que está executando no hardware, mas na verdade está executan-
do sobre outro software. Podemos observar isto na figura abaixo, onde o que é
interessante é a similaridade com a ideia de Java que também esta na figura.
App App App
SO SO
Sw Virtualização App App JVM
Sistema Operacional (SO)

Denis Pacher
Hardware
Figura 41 - Sistema Operacional com virtualização e um JVM
Notamos que o software de virtualização se comporta como uma aplicação

normal, sendo que dentro ela emulou um hardware, dentro dele executamos di-
versos objetos, como na Java Virtual Machine, mas que são sistemas operacio-
nais, e dentro destes podemos ter diversas aplicações disputando o tempo de
execução. O modelo apresentado é um dos que atualmente são empregados no
mercado.
Neste tópico, aprendemos que com a evolução do hardware conseguimos re-
cursos para fornecer sua virtualização e discutimos um modelo para isso.
2.2.4 DESCRIÇÃO DE PROCESSOS COMO VIRTUALIZAÇÃO
Você sabe que um processo é um programa em execução, mas podemos

considerar uma máquina virtual como um processo. Quando pensamos em vir-
tualização pensamos num software como uma máquina de execução Java (JVM),
Virtualbox ou Vmware, as quais fornecem virtualização via software, ou mesmo
o Xen ou KVM, as quais fazem uso das instruções do processador para prover as
facilidades para as máquinas virtuais, o que elas têm em comum?
80
Em comum temos que, quem usa uma aplicação de virtualização, tem a visão
apenas da aplicação abaixo (seja a JVM ou software de virtualização), e não tem
noção do hardware como o todo, apenas da parte que foi alocada à máquina vir-
tual. E o que tem isso a ver com processos em sistemas operacionais?
PROCESSO
Um processo consiste, como dissemos, na instanciação11 em memória do có-

digo executável em disco. Mas o que existe nesse executável? No programa em
disco, temos um código executável, resultado do processo de compilação, onde
estão instruções do programa fonte traduzidas para o código de máquina do har-
dware local, além de instruções para alocar espaço para nossas variáveis e áreas
de trabalho. No disco estão apenas o código e as variáveis e constantes inicializa-
das. O restante é alocado em tempo de carga do programa.
O sistema operacional lê o arquivo do disco, colocando o mesmo em uma área
de memória previamente alocada (no segmento de código), aloca os dados (no
segmento de dados) e aloca uma pilha de trabalho para o processo (Bss ou pilha).
Estas áreas são vistas apenas pelo processo e de seu uso exclusivo, como se corta-
das do hardware, deixadas apenas para o processo. O processador pode ser usado
pelo processo em um mecanismo de tempo compartilhado que você já conhece,
com o emprego de escalonamento em fatias de tempo.
SAIBA Para saber mais sobre o funcionamento de compiladores,

leia “Compiladores - Princípios, Técnicas e Ferramentas” de
MAIS Alfred V. Aho, Ravi Sethi, Addison-Wesley.
O processo, durante cada fatia de tempo, é dono da CPU e das áreas de memó-
ria alocadas aos mesmos. Você pode notar a semelhança entre uma máquina vir-
tual que particiona e isola o hardware e um processo que particiona e isola partes
dele num computador em uma janela de tempo. Podemos pensar nos processos
como máquinas virtuais multiplexadas no tempo, enquanto as máquinas virtuais
reais se aproximam do conceito de multiplexação de frequência.
Uma máquina com suporte a diversos processos se comporta como um har-
dware particionado em diversas máquinas virtuais temporalmente. Enquanto que
em uma máquina virtual alocamos partes do hardware durante todo o tempo de
uso, no sistema operacional alocamos ao processo partes dele somente na sua
fatia de tempo de execução (time slice).
Vimos, neste tópico, que um processo se comporta como uma máquina virtual
particionando o hardware em partes durante um intervalo de tempo.
81
2.3 Arquitetura de Sistemas Operacionais
2.3.1 ORGANIZAÇÃO DE PROCESSOS
Um sistema operacional existe para permitir a execução de aplicações de pro-

gramas no hardware computacional de forma segura e padronizada. Um elemen-
to chave do sistema operacional são os programas em execução, os processos,
que são gerenciados pelo gerente de processos. Vamos discutir as características
desses processos.
O PROGRAMA E O PROCESSO, E SEUS ESTADOS
Quando desenvolvemos uma aplicação e ela é compilada, gera um arquivo

executável que contém o código de máquina compatível com nosso processador.
As variáveis inicializadas e instruções, que informam como o sistema operacional
deve proceder ao colocar o arquivo em memória e executá-lo, incluem a alocação
de memória e pilha para os dados da aplicação, e depois o colocam na fila de
processos para executar.
A figura a seguir ilustra a organização típica de memória de um processo em
execução. Note que o processo está alocado dentro de sua área de memória re-
servada (memória virtual), em que o endereço começa em 0 (zero), e inicia o cha-
mado text, área reservada ao código, seguido da parte de dados (data), heap (para
alocação dinâmica) e stack (pilha do processo).
max
Pilha
estrutura
de dados
dados
Denis Pacher (2012)
texto
0
Figura 42 - Áreas de um processo
Fonte: http://dc146.4shared.com/doc/fu5idfwp/preview004.png
82
Discutiremos os passos de criação de um processo. Antes, devemos lembrar

que um processo pode estar em execução e pode estar esperando por recursos.
Como etapas, temos as ilustradas na figura a seguir, como um diagrama de estado:
Admitted Iterrupt Exit

Now Terminated
Ready Running
Denis Pacher (2012)

scheduler dispatch
I/O of event completion Waiting I/O or event wait
Figura 43 - Diagrama de estado de processo

a) O programa é lido no disco e colocado em memória, sendo alocados os

seus espaços de memória. O processo herda os arquivos abertos e variáveis
de ambiente do processo que o executou, como exemplo, um interpreta-
dor de comandos ou shell. Em alguns sistemas operacionais, para facilitar o
processo de criação do novo processo, como no Unix, é feita uma cópia da
estrutura do processo que está rodando e, em cima dela, é colocado o novo
programa em execução. Isso permite ainda replicar o PCB do processo. Esta
estratégia é conhecida como “fork-exec” devido ao nome das chamadas ao
sistema do Unix.
b) É criado um descritor de processo que diz onde ele estará na memória. Tam-
bém é criado um process ID (identificador de processo, numérico), sendo os
dados do descritor preenchidos com os endereços das áreas de memória
ocupadas pelo processo, bem como seu identificador (process ID). Eles são
colocados no PCB. O processo é dito neste estado como NOVO (NEW).
c) O processo é colocado na fila, esperando seu momento para executar, sen-
do que ao final de cada fatia de tempo, o escalonador pega o processo do
início da fila. Neste estado, dizemos que o processo está pronto, ESPERANDO
PARA EXECUTAR (READY):
a) quando chegar sua vez, o processo irá executar, tendo seu estado mu-
dado para EXECUTANDO (RUNNING). O processo sai deste estado quando
acabar sua fatia de tempo de CPU, voltando para o estado READY, no final
da fila;
b) terminando sua execução, o estado será TERMINADO (TERMINATED);
c) quando necessita de algum recurso de entrada e saída, como um arquivo ou
periférico, neste caso o processo é migrado para o estado ESPERANDO (WAI-
TING). Quando o recurso estiver disponível, o processo volta para READY.
83
Note que na implementação do diagrama de estado temos todas as transições

possíveis de estado para estado. Um processo em NEW não pode ir a WAITING, ou
um em TERMINATED para READY, somente os assinalados.
Para gerenciar estas mudanças, diversas filas são montadas. Por exemplo: uma
para cada estado e o processo é migrado entre elas, sendo que quando vai para
TERMINATED, entra em uma fase de liberação de recursos.
Em relação aos recursos de I/O, é estabelecida uma fila para cada recurso dispo-
nível. Exemplo: se temos uma impressora e um HD, os processos que necessitarem
destes recursos serão colocados em suas respectivas filas, e quando forem atendi-
dos voltarão para o estado READY. Note que um processo pode estar em apenas
um fila ao mesmo tempo, cabendo ao gerente de I/O a manipulação das filas de
dispositivos de I/O e ao escalonador os demais casos de mudança de estado.
O PCB
PCB, o chamado program control block (bloco de controle de programa) listado

anteriormente, constitui o elemento das listas ligadas ao sistema operacional. A
figura a seguir apresenta a organização do mesmo de forma genérica.
process state
process number
program counter
Registers
memory limits
list of open files
Denis Pacher (2012)
...
Figura 44 - Program Control Block (PCB)
Podemos notar que o primeiro elemento é o process state (estado do proces-

so), o qual diz em que estado o processo está, seguido do process number (o iden-
tificador de processo ou process ID), que diz o nome do processo único no sistema
operacional. A seguir, temos a descrição do estado do processo em que aparece
o program counter (contador de programa), o qual diz a próxima instrução a ser
84
executada; os registers (registradores), que contêm uma cópia dos registradores

da CPU; e então os dados sobre memória, arquivos e dispositivos.
O PCB é essencial no processo de escalonamento em multitarefa. Explicamos:
quando colocamos o processo para executar, ele começa da posição zero de me-
mória, e continua executando; quando termina sua fatia de tempo ou o mesmo
vai para I/O, o escalonador salva os dados do contexto do processo no PCB. Estes
dados de contexto são o estado da máquina; quando o processo puder voltar a
executar, basta restaurá-lo e o mesmo continuará de onde parou.
Para conhecer mais sobre processos, leia o capitulo 4 de

“Operating Systems Concepts”, de Abraham Silberschatz, Peter
B. Galvin e Greg Gagne, 8ª edição, da editora Wiley. Note
SAIBA que existe ainda uma versão do texto baseada em Java,
MAIS encontrada em <http://www.wiley.com/WileyCDA/Section/
id-WILEY2_SEARCH_RESULT.html?query=silberschatz&field=
AUTHOR_LASTNAMES&formatRefine=TEXTBOOK&sortField=
dateReverse>.
Vimos que processos são programas em execução e que podem variar seu es-
tado ao longo do seu ciclo de vida.
2.3.2 ESCALONAMENTO E THREADS
Da mesma forma que temos diversos meios de transporte, de um carro a um

trem, podemos ter diversos tipos de sistemas computacionais com objetivos di-
ferentes. Se pensarmos em nossos processos como o que desejamos executar em
um computador, é importante parametrizar o sistema operacional para realizar
a execução dos diversos ambientes que temos. Vamos discutir um pouco sobre
esse assunto.
O ESCALONAMENTO
Ter um processo não é suficiente. Desejamos o mesmo executando, e quem

faz a tarefa de colocar e retirar o processo em execução é o escalonador de pro-
cessos, ou simplesmente escalonador. Existem diversos tipos de escalonadores
no mercado, desde o mais simples, de sistema monotarefa, que simplesmente
coloca o programa para rodar e espera seu término; até o de sistema de tempo
real, que necessita de um tratamento adequado.
85
A primeira característica que temos em um escalonador é de que processos

colocados para executar por ele podem ser interrompidos ou não. Imagine uma
fila de banco na qual existem diversos clientes. Podemos adotar dois modelos:
a) o cliente entra na fila e pode pagar todas as contas que tem em mãos no
seu atendimento, quando terminar de ser atendido, irá embora, e o cliente
seguinte será atendido e assim por diante;
b) podemos estabelecer que o cliente possa pagar apenas 5 contas e, se quiser
outro serviço, é mandado para o final da fila.
Em ambos, o sistema permite o atendimento de diversos clientes. O que muda
é a característica de podermos interromper um atendimento (escalonar) que cha-
mamos de preempção. Em um sistema operacional não preemptivo, a exemplo
da fila de banco, quando um processo assumir a CPU, não vai liberá-la até seu tér-
mino. Em um sistema operacional com escalonamento preemptivo, a tarefa pode
ser interrompida e colocada no final da fila ao acabar sua fatia de tempo. Esta é a
alternativa normalmente mais adequada para nossos sistemas operacionais mul-
titarefa e multiusuários atuais.
Outra característica importante é saber se todos os processos na fila têm a
mesma prioridade para execução ou não. Em sistemas críticos, é importante que
determinadas tarefas tenham privilégio no atendimento. No exemplo da fila de
banco, temos a figura do idoso ou gestante, os quais têm atendimento preferen-
cial. Em sistemas operacionais, a implementação das diversas prioridades é rea-
lizada por um arranjo em várias filas de processo com níveis diferentes (0, 1, 2,..),
em que se atende a fila de menor número primeiro. Um problema neste tipo de
sistema é o que denominamos starvation (ou morrer de fome). Se tivermos mui-
tos processos na fila de mais alta prioridade, as de mais baixa prioridade nunca
serão atendidas. Para evitar o problema de starvation, adotamos a dinâmica de
migrar, depois de alguns ciclos, o processo que está na fila 2 (dois) para a fila 1
(um), para que seja atendido.
Outra característica do escalonador é a possibilidade dele escolher qual pro-
cesso será executado primeiro. Por exemplo, ele pode escolher o processo de
menor, de maior tamanho, o que está mais tempo na fila e assim por diante, de
forma que tenha a menor quantidade de processos em atividade. Estas escolhas
são importantes especialmente em sistemas não interativos.
DEADLOCK
Um dos maiores problemas dentro de sistema operacionais é o chamado

deadlock, ou bloqueio mortal. Ele consiste em um travamento de atividade no sis-
tema operacional onde os diversos programas não executam, pois dependem de
86
recursos entre eles. Isto está relacionado ao que chamamos de concorrência de

12 Hashi processos. Para entender deadlock, usaremos a metáfora proposta por Dijkstra,
Talher oriental formado por “os filósofos jantando”, vista a seguir.
dois pauzinhos, tipicamente
produzidos com bambu.
Denis Pacher (2012)

Figura 45 - Deadlock
Fonte: http://1.bp.blogspot.com/-X5MHeM9BEBM/T140ZTo_UvI/AAAAAAAAAOE/GJA_i79hxqs/s1600/1.png
O problema consiste em uma adaptação livre: cinco filósofos com voto de si-
lêncio resolvem sentar para jantar. O prato está servido, macarrão, e são dispostos
cinco hashis12 na mesa. Um filósofo só pode comer se tiver em mãos dois hashis;
caso contrário, deve esperar.
Observando a figura anterior, tudo pode dar certo. Com cinco hashis, dois fi-
lósofos podem jantar ao mesmo tempo. Ao terminar, eles liberam os talheres e
mais dois podem jantar, e então finalmente o último. Perfeito, os recursos são
suficientes; porém, por uma questão cultural, todos os filósofos ao mesmo tempo
levantam sua mão esquerda e buscam seu hashi à esquerda, e depois, com a mão
direita, buscam o hashi à direita. O que vai acontecer?
Ao pegar o hashi da esquerda, cada um dos filósofos conseguirá um; mas, ao
tentar pegar o da direita, não conseguirá e ficará esperando. Na verdade, todos os
cinco têm um hashi, e ficarão esperando eternamente pelo o outro recurso para
jantar, morrendo todos de fome. Daí o nome bloqueio mortal, deadlock. Tínha-
mos os recursos para resolver o problema, mas sistematizamos para uma solução
que levou a problemas.
COMO RESOLVER O PROBLEMA DE DEADLOCK?
Podemos ignorar o problema. O primeiro filósofo que morrer liberará um hashi e

temos uma solução (neste caso não estamos tratando o problema). Podemos ado-
tar a regra de que se um filósofo pegar um hashi e não conseguir pegar o outro, que
ele o coloque de volta e pense um número aleatório, e, somente depois de contar
até este número, tente pegá-lo novamente. Isso certamente resolverá o problema.
87
Na verdade, existem diversas soluções propostas na bibliografia para detecção

e resolução de deadlock, mas tipicamente na implementação do sistema opera-
cional, a solução primária é ignorar o deadlock (isso explica, dentre outras coisas,
por que um programa travado no Windows não responde).
Em computação não temos hashis, mas arquivos, periféricos e outros recur-
sos compartilhados entre os programas. Um exemplo: ao acessar a internet via
navegador, como o Firefox, você se depara com um pdf. O Firefox irá acionar o
Acrobat Reader ou outra solução para processar o pdf. No caso, o Acrobat vai ficar
esperando o arquivo que o navegador busca na internet, e o navegador, por algu-
ma razão, pode ficar esperando um recurso do Acrobat e assim nenhum dos dois
funcionará. Casos como este, infelizmente, são comuns. O que podemos fazer é
terminar um ou mais processos manualmente, já que o sistema operacional não
conseguirá. Isso é o que chamamos de ambiente produtor-consumidor.
Para conhecer mais sobre deadlock, leia <http://maykonlb.

SAIBA blogspot.com.br/> e o capítulo 8 de “Operating Systems Con-
MAIS cepts”, de Abraham Silberschatz, Peter B. Galvin, Greg Gagne,
8ª edição, da editora Wiley.
O CUSTO DE ESCALONAMENTO E CRIAÇÃO DE PROCESSOS
Você sabe como um processo é criado e agora como o mesmo pode ser esca-
lonado. Levando em conta diversas estratégias e alguns problemas que podem
surgir, ficam algumas perguntas: quanto custa criar um novo programa? Quanto
custa o escalonamento?
Por questão de segurança, quem pode mexer em recursos do sistema opera-
cional é apenas o sistema operacional. Logo, dividimos a memória do computa-
dor em um bloco que vai de zero a n, onde armazenaremos o sistema operacional
e fixaremos um registrador no sistema de paginação do hardware de memória
para assinalar a atividade. Para acessar esta área de memória, devemos estar no
chamado modo sistema, isto é, no sistema operacional. Acima deste endereço, os
programas podem acessar: chamamos de modo usuário.
Aplicações executam sempre em modo usuário e sistema operacional em modo
sistema. Existe um custo para chavear entre esses modos: toda vez que escalona-
mos um processo ou criamos um novo processo, temos este custo de mudança
de modo. O que fazer se precisarmos ter um escalonamento e também criação de
forma mais ágil, como um servidor web que precisa atender simultaneamente di-
versas chamadas? Podemos criar um novo processo para cada chamada, ou, para
88
este tipo de aplicação em que para todas as unidades em execução só mudam-se

a área de dados (mantendo o mesmo código), podemos tentar algo novo.
Esse algo novo chama-se thread ou linha de execução. Em um ambiente mul-
tithread (hoje quase todos os sistemas operacionais suportam), ao criar uma nova
cópia do processo, fazemos isso dentro da aplicação sem invocar o sistema ope-
racional, apenas replicando as áreas de dados e compartilhando a de código. Esta
estratégia permite um ganho muito grande em desempenho.
Vimos neste tópico o funcionamento do escalonador e problemas relaciona-
dos a ele, bem como o conceito base de thread.
2.3.3 IPC - COMUNICAÇÃO ENTRE PROCESSOS
Imagine você sendo um funcionário em uma indústria e, no seu setor, traba-

lham juntos outros realizando tarefas semelhantes ou que dependem do que
você está fazendo. Devemos concordar que a comunicação entre estas pessoas é
essencial, certo? De mesmo modo, se pensarmos em uma máquina com diversas
aplicações e processos executando, que visam a resolver um problema, deverão
se comunicar. Veremos, neste tópico, como isto é feito no sistema operacional.
IPC - INTER PROCESS COMMUNICATION
O módulo de comunicação entre processos (inter process communication -

IPC), do gerente de processo, é responsável por ordenar a comunicação entre as
aplicações que estão em execução. O objetivo básico de IPC é permitir que, no
ambiente de uma máquina gerenciada pelo sistema operacional, exista comuni-
cação entre os diversos processos que estão sendo executados.
Diversas abordagens existem para permitir o compartilhamento de informa-
ções. Conheça as principais.
a) Memória compartilhada
Com o mecanismo de memória compartilhada, se um processo A deseja tro-
car informações com o processo B, A aloca uma área de memória dinami-
camente e compartilha a mesma com B. Nesta área, os dados postos serão
visíveis pelos dois processos, sendo que para sua implementação o sistema
operacional deve fornecer suporte adequado ao módulo de gerência de me-
mória, tipicamente por um mecanismo de paginação, em que mapeamos
a mesma área de memória (mesmo que com endereços virtuais diferentes)
para dois processos. A figura a seguir mostra um modelo típico de alocação.
89
Stack Stack
shared library shared shared library

pages
heap heap
data data
Denis Pacher (2012)

code code
Figura 46 - Memória compartilhada

Fonte: http://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/images/Chapter9/9_03_SharedLibrary.jpg
Atenção, já que esta área é comum e que os processos são escalonados no

tempo, devemos assegurar que exista um controle de acesso adequado à
memória compartilhada. Chamamos este controle de acesso a recursos co-
muns de sincronização de processos, que pode ser obtida por mecanismo,
como semáforos.
Um semáforo consiste em uma variável compartilhada entre dois processos
em que fazemos o setup com valores zero (0) e um (1), por exemplo, para di-
zer se uma aplicação pode fazer algo ou não. Pense em um protocolo do tipo
XON-XOFF para controle de enlace, ele é um tipo de semáforo. Semáforos
são muito úteis igualmente para lidar com o problema produtor-consumi-
dor, onde um processo gera dados e o outro consome (processa) os dados.
b) Mensagens
Outro enfoque seria definir as primitivas send e receive, que deixa enviar uma
mensagem (send) ou receber (receive) entre processos. O uso de mensagens
permite comunicação entre processo de forma direta, sendo que, se enviar-
mos várias delas para um determinado processo, serão colocadas em uma fila.
Por isso este método é chamado de fila de mensagens em alguns momentos.
O sistema Unix implementa os chamados sinais através

VOCÊ do mecanismo de mensagens e interrupção, permitindo
a geração de eventos entre processos. Maurice J. Bach
SABIA? definiu como é feito isto em seu livro “The Design of the
UNIX Operating System”.
90
c) Pipes
Pipes são abordagens criativas de comunicação. Considere uma aplicação
que liste os arquivos em um diretório, um ls do Unix, por exemplo. A lista
é gerada de forma não ordenada. Se quisermos, podemos usar o aplicativo
sort para ordenar a saída e mostrar na tela de forma ordenada. Essa solução
seria a indicada a seguir, onde jogamos a saída do ls em um arquivo temp1 e
usamos o sort para ordenar.
ls > temp1
sort temp1
A questão é que estamos gerando um arquivo temporário inútil e este tipo
de problema é comum entre processos. Uma solução seria jogar a saída do
ls para o sort direto, mas como? A solução são os pipes, ou dutos, se preferir.
Um processo possui, associado a ele, arquivos padrões de entrada (stin), sa-
ída (stout) e erros (sterr) no Unix. Toda entrada interativa vem do stin e saída
vai para stout. A solução de pipe permite ligar a saída de um processo A à
entrada do processo B. Podemos expressar isto com o |. No caso, o comando
para representar a situação vista acima seria:
ls | sort
Para saber mais sobre os métodos descritos de IPC, bem

SAIBA como métodos de comunicação via rede, cliente servi-
dor, leia o capítulo 4 de “Operating Systems Concepts”, de
MAIS Abraham Silberschatz, Peter B. Galvin, Greg Gagne, 8ª edi-
ção, da Wiley.
Vimos, neste tópico, que a comunicação entre processos é essencial e que

pode ser realizada de diversas formas, entre elas: mensagem compartilhada,
mensagem e pipes.
2.3.4 GERENCIAMENTO DE MEMÓRIA
A memória principal, introduzida como elemento chave da arquitetura de Von

Neumann, assume atualmente um papel essencial no desempenho, segurança
e funcionalidade dos sistemas computacionais. O Gerenciamento da memória é
realizado por uma junção de hardware, Management Memory Unit (MMU) e sof-
tware, que estudaremos neste módulo de gerenciamento de memória do sistema
operacional.
91
O CONCEITO FÍSICO
A memória pode ser considerada como conjunto finito de espaços de armaze-

namento com capacidade de 1 byte (8 bits) que podemos endereçar byte a byte.
Digamos que temos 1024 bytes de memória, 1 Kbyte, e você pode acessar (ler/
alterar) o valor do byte na posição que vai de 0 a 1023. Nomeamos esta facilidade
de acessar uma posição de memória de endereçamento, e a posição de um deter-
minado byte será o seu endereço na memória.
A VISÃO DO USUÁRIO
Do ponto de vista do usuário final, a memória é um conjunto de bytes sequen-

ciais, em que enxerga do endereço 0 a n, sendo n o tamanho de memória supor-
tado pelo sistema computacional.
O HARDWARE
O hardware implementa o controle, alocação e gerência de memória por meio

de dois conceitos: a segmentação e a paginação. Um conceito extra é o de me-
mória virtual.
Enquanto em outros momentos o sistema operacional desempenha um papel
forte na gerência de memória grande, parte do mérito cabe ao hardware.
A SEGMENTAÇÃO
Observando que um programa em execução possui áreas funcionais distintas,

desenvolveu-se nos processadores o conceito de segmento da memória que con-
siste em um espaço de memória, com endereçamento sequencial de tamanho
específico.
Normalmente, o processador suporta os segmentos de dados, código e de pi-
lha, podendo suportar outros.
Ao colocar um programa em execução, o sistema operacional aloca para suas
instruções uma área de memória que será o segmento de código. Para os dados, é
alocado um segmento de dados, e para trabalhar os procedimentos ou módulos,
temos o segmento de pilha e a pilha do sistema operacional. O uso de segmentos
permite que cada programa tenha seu código iniciando no endereço 000 de me-
mória, o mesmo para os dados e para a pilha. Este fato foi importante na evolução
dos sistemas operacionais quando se tornaram multitarefa/multiusuário.
92
1400
stack Segment 0
subroutine
2400
segment 3
segment 0
symbol
table limit base 3200
0 1000 1400
1 400 6300
segment 4
Sqrt 2 400 4300 Segment 3
3 1100 3200
4 1000 4700
4300
main Segment 2
Segment table
segment 1 program 4700
segment 2 Segment 4
logical address space 5700
Denis Pacher (2012)

6300
Segment 1
6700
physical memory
Figura 47 - Segmentação de memória

Fonte: http://andrewharvey4.files.wordpress.com/2010/07/segmentation.png?w=600
O mecanismo de segmentação (figura acima) é gerenciado e praticado pelo

processador sem a participação ou interferência do sistema operacional sendo
um elemento transparente ao mesmo.
A PAGINAÇÃO
Enquanto o mecanismo de segmentação apresenta uma solução interessante

por espelhar a forma como um programa é desenvolvido e executado na aloca-
ção da memória pelo hardware, o mesmo não garante proteção à memória de
diversos processos, executando quando não desejamos que um processo veja
os dados do outro ou que possa alterá-los. O que fazer quando, em especial, não
desejamos que um processo de usuário veja ou altere o processo, ou processos,
do sistema operacional?
93
Virtual Address: T Z Y X
16 6 6
VPN Flags PPN 16 64
PPN DATA
verif
Denis Pacher (2012)

VPN_save PPN_save
28
DATA
Figura 48 - MMU
Fonte: https://www-soc.lip6.fr/trac/tsar/raw-attachment/wiki/VirtualMemory/cache_tlb.png
O mecanismo proposto foi o de paginação. A ideia é dividirmos a memória

física endereçável em páginas de tamanho fixo e quando alocarmos a memória a
um processo, a alocação será feita em páginas. O mecanismo exige que seja exe-
cutado pelo MMU do processador. Veja uma breve descrição do processo através
de exemplo a seguir.
Se assumirmos uma memória de 10000 bytes e consideramos que esta será
dividida em páginas de 100 bytes:
A MMU é programada com o tamanho da página. Foi usada 100 bytes pelo ge-
rente de memória do sistema operacional. Neste caso, teríamos a página 0 (zero)
começando no endereço 0 (zero) e indo até o 99, a página 1 começando em 100
e indo até 199, e assim até mapear toda a memória.
Abaixo temos a carga padrão da MMU para o exemplo:
Quadro 2 - Número de página e endereço inicial para o exemplo
Número da página Endereço inicial

0 0
1 100
2 200
3 300
... ...
Fonte: Autor
No exemplo, ao acessar o endereço 150, o MMU descobre em que página está

o endereço e o acessa. No acaso, sendo página 1, acessará ao endereço 150.
94
Então, qual é a novidade? Cada processo possui uma tabela de páginas aloca-
das. Esta tabela é carregada na MMU quando o processo é escalonado.
Digamos que os processos A, B e C são os das seguintes tabelas de página:
Processo A
5
6
7
-
Processo B
10
Processo C
Os endereços válidos serão de 0 a N, sendo que ao escalonar o processo, a sua

tabela de páginas é carregada na MMU.
No caso do processo A, temos:

a) página 0 corresponde à página 5 do hardware, isto é, endereços que vão de
0 a 99 são mapeados em endereços que vão de 500 a 599. Se acessamos o
endereço de memória 76 do processo A, estaremos acessando o endereço
físico de memória 556;
b) página 1 corresponde à página 6 do hardware (endereços entre 100 e 199
serão mapeados endereços de 600 a 699);
c) a página 2 corresponde à página 7 do hardware.
No processo B, temos a visão de que o mapeamento não precisa ser sequen-
cial. Vejamos:
95
Se acessarmos o endereço 0 de B, estaremos acessando o endereço físico 1000.

Ao acessar o 99, será o 1099, mas ao acessar o endereço 100 estaremos acessando
o endereço físico 800.
Fisicamente as páginas são não sequenciais, mas para o usuário é mostrado
apenas uma noção contínua de endereços. Podemos usar o mecanismo de pagi-
nação associado à segmentação e de forma totalmente transparente.
A MEMÓRIA VIRTUAL
Com a ideia de paginação, usamos o mecanismo de memória virtual via swap-

ping, em que ao faltar memória física será gravada uma ou mais páginas em disco
e alocadas as mesmas ao novo processo escalonado. No processo que teve as
páginas guardadas em disco, as marcamos em sua tabela de páginas como dirty
(suja), de forma tal que quando o processo for escalonado, a página será colocada
em memória de novo.
Para guardar as páginas em disco, usamos uma partição de disco especialmen-
te formatada para tal, ou de um arquivo. A opção de qual usar depende de cada
sistema operacional.
A SEGURANÇA OFERECIDA PELA PAGINAÇÃO
Desejamos em um sistema operacional multitarefa e multiusuário em relação

ao controle de acesso à memória:
a) que uma aplicação de um usuário não veja os dados do outro;
b) que uma aplicação não possa interferir no sistema operacional.
Como garantir isto?
O mecanismo de paginação permite executar as duas premissas já que temos
nos dois casos:
a) uma aplicação não vê os espaços de memória da outra porque o endereço
010 da aplicação A está mapeado em um espaço de memória, e o 010 de
uma aplicação B em outro espaço por outra página. Se um aplicativo tentar
acessar um endereço fora do espaço alocado para ele, temos um page falt;
b) para proteger o sistema operacional é simples. Se o sistema operacional
gasta, digamos,1000 bytes (10 páginas no nosso exemplo), comece a alocar
às aplicações a partir da página 11 física. Logo, nenhuma aplicação conse-
guirá acessar e alterar os dados no espaço de memória reservado ao sistema
96
operacional, podendo interagir com este apenas via API (normalmente via
mecanismo de interrupção).
O PAPEL DO GERENTE DE MEMÓRIA
Como vimos, o gerenciamento de memória é feito pelo hardware incumbindo

apenas ao sistema operacional controlar as alterações e carga das tabelas de página
a cada escalonamento. Parece simples, mas foram muitos anos para chegar a ele.
2.3.5 SISTEMAS DE ARMAZENAMENTO SECUNDÁRIO
Você já pensou se não tivéssemos memória, se o que sabemos fosse esqueci-

do quando dormíssemos? Computadores possuíam este comportamento, havia
informações somente quando estavam ligados. Nesta fase o sistema computa-
cional era composto apenas por canais de entrada e saída, memória e processa-
dor. Para suprir esta deficiência, foram desenvolvidos periféricos que armazenam
informações enquanto o computador está desligado, são chamados dispositivos
de armazenamento secundários. Vamos discutir um pouco sobre os mesmos e
a forma que foram usados em sistemas operacionais para se permitir utilização
mais amigável do armazenamento secundário, os chamados sistemas de arquivo.
O sistema de arquivos pode ser visto como dois grandes módulos: o primeiro,
executa nossa visão de arquivos, com nomes de arquivos e outros; o segundo,
mapeia os blocos físicos dos dispositivos de armazenamento para formar nossos
objetos lógicos.
A VISÃO LÓGICA DE ALTO NÍVEL
No mundo real, estamos acostumados a organizar informação em armários,

fichários, pastas e outros. No virtual, quando se pensou no conceito de armazena-
mento secundário, a semântica proposta foi a de termos um sistema de arquivo
onde tivéssemos a organização próxima ao mundo real.
A ideia é termos objetos chamados de arquivos que contenham dados. Cada
arquivo possui alguns predicados chaves, dependendo do sistema operacional.
a) Nome: especifica um identificador único de forma tal que possamos solici-

tar o objeto. Também pode ter uma extensão (.bat , .exe, .doc ) que identifica
uma ação especial que o sistema operacional pode realizar sobre ele (.exe
nos sistemas Microsoft, por exemplo, identifica arquivo executável), ou que
97
pertence a um determinado aplicativo (.odt identifica um arquivo de docu-

mento do padrão ODF). A ideia de extensão consiste em uma informação
que nem sempre é empregada nos sistemas operacionais.
b) Controle de acesso: temos a noção de dono do arquivo e grupo a qual per-
tence, se é executável, somente de leitura, e tantos outros controles.
c) Tamanho: a quantidade de bytes que possui.
d) Localização: especifica onde o arquivo está localizado no sistema de
diretórios.
O DIRETÓRIO
O conceito de diretório equivale ao da lista telefônica onde organizamos a

informação de forma hierárquica. Na década de 70, o sistema operacional Unix
propôs a organização de sistema de arquivo em árvore, a qual tem sido a principal
opção no mercado.
No modelo base, temos uma raiz que é um diretório. Dentro deste, nas folhas
que são nossos arquivos, e também subdiretórios (se comportam da mesma for-
ma que o diretório), podemos ter arquivos e subdiretórios internamente. A figura
abaixo espelha o processo:
root spell bin programs
stat mail dist find count hex reorder p e mail
prog copy prt exp reorder list find hex count

Denis Pacher (2012)
list obj spell all last first
Figura 49 - Sistema de diretório em árvore

Fonte: <http://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/images/Chapter10/10_09_TreeStructure.jpg>
O Unix propôs a ideia de termos o diretório raiz (o/) como ponto de acesso ao
sistema e demais arquivos nele. A Microsoft, com o MS DOS, propôs a visão de um
98
sistema de arquivos diferentes com cada unidade física de disco ou lógica (parti-
ção) complicando a localização de um arquivo. Assim, se mudarmos o nome de
uma unidade de J para H, por exemplo, um arquivo que sabíamos onde estava,
ficaria inacessível para quem desconhece a mudança. Nas versões mais novas do
Windows, temos uma visão semelhante a do Unix, com um ponto de montagem
onde todos os arquivos são acessados.
Conhecemos esta abstração de acesso ao armazenamento secundário como
VFS (Virtual File System - Sistema De Arquivo Virtual).
Para saber mais sobre árvores, acesse <http://en.wikibooks.

SAIBA org/wiki/Data_Structures/Trees>
MAIS Sobre outras organizações de diretório leia o livro “Operating
Systems Concepts”, de Silberchatz.
A SEGURANÇA
Um elemento chave executado pelo sistema de arquivos é a proteção às infor-

mações do usuário, seja através da proteção dos arquivos de dados, ou do contro-
le de alteração nos arquivos executáveis.
Em sistemas operacionais monousuário, existe a noção de que o sistema, seja
software ou hardware, pertence ao usuário. Com o aparecimento dos sistemas
operacionais multiusuários, surge a necessidade de um mecanismo de controle
de acesso aos seus recursos e em especial aos arquivos. Este mecanismo é im-
plementado via identificação (um nome de usuário), autenticação deste usuário
verificando que ele é quem diz ser (por uma senha, biometria ou qualquer outro
método) e finalmente a conceder privilégios do que o usuário pode fazer no sis-
tema (autorização).
Os diversos sistemas operacionais no mercado implementam mecanismo de
segurança no controle de acesso de formas diferentes. O Unix representa a solu-
ção clássica, em que temos para um arquivo os papéis de:
a) Dono (owner/user): quem criou o arquivo;
b) Grupo (group): o grupo de usuários a que o arquivo pertence;
c) Todos (All): todos os usuários no sistema.
O Unix programou o controle de acesso baseado em ações de leitura, escrita e
execução em um arquivo, sendo que podemos gerar restrições para o dono, grupo
ou todos. Por exemplo: um arquivo pode ser de leitura e escrita para o dono, so-
mente leitura e execução para o grupo, e sem permissão para os demais usuários.
99
A abordagem do Unix foi inovadora no início da década de 70. Na década de 90,

o Windows NT passou a dar um enfoque presente na maioria dos sistemas opera-
cionais atuais: a ACL (Access Control List - Lista de controle de Acesso) onde associa-
mos a cada arquivo, uma lista de quem pode acessá-lo e o que pode fazer com ele.
Se pensarmos que memória virtual é implementada em disco, a garantia de
mecanismo de controle de acesso se torna mais importante ainda no âmbito de
sistema de arquivos.
O ARMAZENAMENTO
A visão de alto nível provida pelo VFS é uma abstração muito importante, mas
devemos lembrar que os arquivos são armazenados em discos, DVDs, fitas e ou-
tras mídias. Dada a diversidade de formas como armazenamos os dados, deve-
mos ter um tratamento especializado para cada mídia.
A ideia básica no armazenamento de baixo nível é de termos, associado aos
metadados do arquivo/diretório presentes no VFS, algum mecanismo de lista de
blocos de armazenamento da mídia. Encontramos diversos formatos e o Unix tra-
balha com a tabela de inodes, em que temos ponteiros em um descritor para
diversos blocos do disco, e se o inode do arquivo não suportar a quantidade de
blocos necessária, podemos ter um ponteiro, um novo descritor com índices ape-
nas. Veja a figura abaixo:
Directory Entry
Name
Size
Direct block pointers
0
1
2
3
4
5
6
7
8
indir_ptr 0
9
indir_ptr 1
indirect block
doubly indirect block
indir_ptr 0 indir_ptr 0
indir_ptr 1 indir_ptr 1
Denis Pacher (2012)
indir_ptr 0
indir_ptr 1
Figura 50 - Estrutura de inodes do Unix

Fonte: http://www.read.cs.ucla.edu/111/_media/2006fall/notes/direntry2.jpg
100
No ambiente da Microsoft, encontramos a estrutura de tabela de índices da

FAT e depois a lista de blocos do NTFS.
Diversas estratégias são empregadas para tentar se garantir que arquivos es-
tejam armazenados com seus blocos de disco em sequência, para garantir maior
velocidade, sendo que quando não conseguimos isso, temos uma fragmentação
de disco.
OS SISTEMAS DE ARQUIVOS
Cada sistema operacional opta, na maioria das vezes, por criar um sistema de
arquivos para que se apresente um gerenciamento eficaz do armazenamento fí-
sico, sendo que em alguns momentos temos apenas a mudança do nível de VFS
(um exemplo é o Linux com a alocação de disco baseado em inodes do Unix e
podendo apresentar visões ao usuário como o EXT2, EXT3, JFS e outros).
Vimos, neste tópico, que diversos sistemas de arquivos existem no mercado,
sendo que os mais comuns, utilizados no dia a dia, são os do Linux e Windows NT.
2.3.6 SISTEMAS DE ARQUIVO EM REDE
Pense como seria se a internet ou as redes locais não existissem. Como com-
partilharíamos arquivos?
Antes da década de 1980, não tínhamos o problema, já que todos os arqui-
vos residiam no mainframe. Nem faria sentido falar em compartilhar arquivos via
rede. Com a introdução dos microcomputadores, a solução para o problema foi
compartilhar arquivos por meio de disquetes. Nada eficaz, mas atendia. Com seu
uso frequente nas empresas, surgiu a necessidade de interligar os computadores
e garantir algum mecanismo de compartilhamento de arquivos, hoje uma regra.
Do ponto de vista de sistema operacional, a Sun resolveu o problema no siste-
ma operacional Sunos (antecessor do Solaris,1985): utilizando a abstração de que
no sistema de arquivos temos o VFS (Virtual File System), uma camada que permi-
te separar como tratamos os arquivos em diretório, por exemplo, ou atributos da
parte de controle de armazenamento em disco dos arquivos (no Unix, tabela de
inodes), a Sun propôs o modelo em que o sistema de arquivo remoto fosse visto
como mais um dispositivo para armazenamento, de modo que as aplicações não
percebessem a diferença (esse fato é denominado de transparência de acesso).
A partir daí, foi desenvolvida uma série de tecnologias que são base de nossos
sistemas de arquivos em rede atuais.
101
a) RPC (Remote Procedure Call): chamada de procedimento remoto, permite

escrever aplicações de rede de forma mais simples do que usar os sockets
TCP/IP com a possibilidade de chamar procedimentos em outras máquinas.
b) NFS (Network File System): sistema de arquivo em rede, era o modelo de
implementação de compartilhamento de arquivos da Sun. A figura a seguir
ilustra o NFS.
Denis Pacher (2012)
Figura 51 - Network File System SUN

Fonte: http://www.cs.uic.edu/~jbell/CourseNotes/OperatingSystems/images/Chapter11/11_15_NFS_Schematic.jpg
c) NIS (Network Information System): sistema de informação da rede que des-

creveremos a seguir.
A NECESSIDADE DE AUTENTICAÇÃO
Em um ambiente sem rede, cada usuário é responsável por sua máquina, man-
tendo senha de acesso local, muitas das vezes via BIOS. Quando pensamos na
conexão dos computadores em rede, e a possibilidade de termos os arquivos re-
motos, qualquer um acessaria os mesmos, quebrando o requisito de confidenciali-
dade deles. Como garantir que só a pessoa autorizada tivesse acesso aos arquivos?
A Sun, da mesma forma que elaborou o RPC, viu que o caminho não era ter
contas de usuários locais em cada máquina, mas ter um serviço de rede integran-
do toda a base de informações da empresa, incluindo os nomes de usuários e
senha, bem como informações de nomes de máquinas, dentre outros, e que pu-
desse ser acessível a todas as máquinas. Criou então o NIS, que, integrado ao NFS
e RPC, são os pilares do compartilhamento de arquivos em rede.
102
Contudo, a solução NFS, RPC e NIS estava restrita ao Unix em um primeiro mo-
mento e ao Sunos da Sun, mas por ter especificação aberta, foi adotada pelos
demais fornecedores do mercado Unix.
NO MUNDO PC E ATUALMENTE
O mercado IBM PC, que surgia na década de 1980, adotou a solução de com-
partilhamento de Novell, o de netware e, posteriormente, a solução de comparti-
lhamento de arquivos da Microsoft (CIFS), padrão hoje no Windows. A solução da
Microsoft, introduzida com o Windows NT, apresenta grande similaridade com o
NFS da Sun. Até por ter surgido bem depois, podemos dizer que é quase idêntica.
Hoje, os conceitos introduzidos pelo NIS são implementados pelo Serviço de
Diretório, tendo como padrão de referência o X.500, e como principais produtos o
LDAP e o Active Directory (AD da Microsoft), ambos baseados no padrão.
Vimos os conceitos básicos de sistema de arquivo em rede e um pouco do his-
tórico de como surgiram. Atualmente, esses serviços alcançaram uma dimensão
global com a internet e a adoção dos serviços em nuvem computacional.
2.3.7 ENTRADA E SAÍDA
Em arquitetura de computadores, temos a visão clara das partes que compõem

o computador, sendo que associamos no sistema operacional um gerente para
cada grande parte, seja o processador (gerente de processos) e a memória (ge-
rente de memória), os quais constituem a base do processamento; seja a noção
de arquivos e diretórios (gerente de arquivos). A interação com os periféricos cabe
ao gerente de I/O, ou de entrada e saída, se preferir. Vamos discuti-lo neste tópico.
Historicamente, em computação, denominamos qualquer periférico de meca-
nismo I/O. Enquanto que em um sistema computacional sempre existirão arqui-
vos, processos e memória em comum, não se pode dizer o mesmo em relação a
periféricos. Teremos uma impressora em uma máquina, e em outra, um scanner,
isso sem levar em consideração que existem dezenas de modelos de impressoras
e scanners com suas particularidades. Devido a gama variada de periféricos e a
possibilidade de surgirem outros a cada dia, o gerenciamento de I/O no sistema
operacional é dividido em uma parte minimalista que está no núcleo do sistema
operacional e em softwares especializados para cada dispositivo: os device drivers
ou drivers de dispositivo.
103
DEVICE DRIVER
Um device driver, conhecido como driver de dispositivo, é uma porção de códi-

go especializada em tratamento de determinado periférico ou dispositivo. Uma
característica interessante é que o sistema operacional fornece apenas suporte
aos dispositivos mais usados no mercado, sendo responsabilidade do fabricante
de hardware fornecê-lo. Este software deve ser posteriormente instalado junto ao
Você deve estar se perguntando como é este software e como se comunica
com o sistema operacional. A figura a seguir apresenta um modelo típico de siste-
ma operacional no que se refere a drivers de dispositivo.
Kernel
software
Kernel I/O subsystem
SCSI Keyboard Mouse PCI bus floppy ATAPI

device device device device device device
driver driver driver driver driver driver
SCSI Keyboard Mouse PCI bus floppy ATAPI

device device device device device device
controller controller controller controller controller controller
hardware
ATAPI
floppy devices
SCSI
Denis Pacher (2012)
Keyboard Mouse PCI bus -disk (disks,

devices
drivers tapes,
drives)
Figura 52 - Driver de dispositivo
Quando o Unix foi desenvolvido, considerou-se que seria conveniente que o

sistema operacional tivesse uma forma uniforme de interagir com vários drivers
de dispositivos de diferentes fabricantes, de modo que pudessem ser acoplados
ao sistema operacional sem alterações nele. A solução proposta foi tratar os peri-
féricos como arquivos. A ideia básica é que podemos realizar algumas operações
sobre arquivos:
104
a) CREATE - criar o arquivo vazio alocando estruturas para o mesmo;

13 Semântica
b) OPEN - abrir o arquivo;
Em programação,
descreve o significado c) WRITE - escrever dados no arquivo;
de construções sintáticas
válidas. d) READ - ler dados do arquivo;
e) CLOSE - fechar o arquivo.
A equipe de desenvolvimento do Unix propôs que estas funções, com peque-
nas alterações, fossem implementadas por todos os device driver. A mudança foi
de no lugar de CREATE usar o INIT, que inicializa o dispositivo.
Se quisermos usar uma placa de rede, por exemplo, depois do driver de dispo-
sitivo da placa ser instalado no sistema operacional, a primeira coisa que o sof-
tware fará, ao ser carregado, é inicializar a placa de rede. Isso significa mandar
comandos para a controladora na placa.
Por exemplo: quando mandarmos algum pacote de dados para a rede, o sis-
tema operacional chama a função WRITE da placa de rede (de seu driver) e passa
a localização dos dados como parâmetro. De forma equivalente a um arquivo,
o driver receberá os dados e fará o envio via rede, uma função especializada. Se
chegarem dados à placa, ela avisa o processador via mecanismo de interrupção
que chamará a função READ da placa de rede, e assim por diante.
O interessante é que, conhecendo a sintaxe de como as funções básicas são
executadas (os parâmetros), podemos escrever um driver de dispositivo para o
sistema operacional, obviamente conhecendo o funcionamento do hardware.
Ressaltamos que o driver de dispositivo faz o meio de campo entre o hardware e
o sistema operacional. Neste caso, devemos conhecer plenamente os parâmetros
de configuração do dispositivo: interrupção (IRQ); endereçamento de I/O; porta;
canal de DMA; e em alguns casos o endereço do firmware/BIOS da controladora.
O driver de dispositivo tem estes dados, quase sempre obtidos da BIOS PnP ou
configurados manualmente, isolando o resto do sistema operacional de conhecer
detalhes do hardware, tratando-o como um arquivo, o que facilita o desenvolvi-
mento de aplicações.
Esse modelo foi reforçado quando a IBM optou por não patentear o IBM PC e
induzir o mercado a desenvolver seus hardwares periféricos, ficando a cargo tam-
bém de escrever os drivers de dispositivo. O sistema operacional da época, o MS-
-DOS, e o Windows, ambos da Microsoft, usam o mesmo modelo de tratamento
de periféricos do Unix com drivers de dispositivo.
105
DISPOSITIVOS DE CARACTERES DE BLOCO
Existem periféricos que permitem ler ou escrever para o mesmo byte a byte.
Um exemplo é o teclado. Há outros também que enviamos ou recebemos blocos
de dados, como, por exemplo, o disco rígido (HD), onde trabalhamos com a no-
ção de setor de 512 bytes.
Na implementação do driver de dispositivo, levamos em conta a possibilidade
de um dispositivo suportar apenas escrita ou leitura. Um monitor, por exemplo,
suporta apenas escrita.
O Unix e suas variantes (Linux, BSD, Mac OS X e Android, dentre outros) man-
têm os drivers mapeados em arquivos no diretório /dev. No Unix, se você copiar
algo para o /dev/lpt0, estará mandando o arquivo para a impressora. No MS-DOS/
Windows, se copiar algo para o PRN, mandará o arquivo para impressora.
Hoje, com a popularização dos hardwares que o usuário pode montar e des-
montar, em especial USB, surge a necessidade de instalação de softwares para
usar o dispositivo, sendo que somente o administrador pode instalar este driver
de dispositivo. Surgiu como solução a ideia de colocar o driver de dispositivo em
espaço de usuário (user space), permitindo uma maior flexibilidade de uso do har-
dware pelo usuário final.
Neste tópico, vimos como os dispositivos são suportados pelo sistema opera-
cional, realizando um casamento harmônico entre hardware e software, via drivers
de dispositivos que implementa uma semântica13 de arquivos.
2.3.8 AMBIENTES: MULTIPROCESSADOS, PARALELO E DISTRIBUÍDO
Certamente, você já instalou um sistema operacional Windows e/ou Linux em

um computador, estando este local sem conexão à rede alguma. Discutiremos
alguns aspectos que modificam a forma como trabalhamos a computação e que
impactam o sistema operacional, em especial o cenário de multiprocessamento,
paralelismo e ambiente distribuído.
Ambiente Multiprocessado
Um ambiente multiprocessado consiste em um sistema computacional em

que temos mais de um processador na máquina. No modelo tradicional, temos
vários processadores que são coordenados através da especificação SMP (sime-
trical multi processing) implementada no hardware. O SMP garante que, tendo di-
versos processadores ligados aos barramentos do sistema, cada um tenha direito
106
de acesso à memória que é global a todos, ou seja: se a memória começa no en-

dereço e segue até o endereço 4 GB, todos os processadores verão esta memória.
Se pensarmos no sistema operacional como um elemento que gerencia re-
cursos, em especial o tempo de processamento através da fila de processos, te-
ríamos, em um modelo tradicional, algo em que todos os processos são servidos
pelo mesmo processador.
Você deve estar se perguntando: se tenho quatro processadores terei o siste-
ma quatro vezes mais rápido?
Não exatamente. A tarefa de gerenciar a distribuição de carga entre os diver-
sos processadores, bem como a concorrência por acesso à memória, leva a um
desempenho menor do que a mera multiplicação. Podemos encontrar ainda pro-
blemas de concorrência, processos que não tinham sido notados ainda devido à
serialização de processos aqui. Como exemplo, temos a possibilidade de deadlock
e problemas de compartilhamento de memória.
Há algum tempo, a ideia de multiprocessamento era associada apenas a am-
biente de servidores. Mas hoje ocorre a popularização dos processadores multi-
core, em que na essência cada núcleo constitui um processador, onde podemos
considerar um processador com 8 núcleos como um sistema como 8 processado-
res (claro, a complexidade de gerência física de memória aqui será menor). Logo,
sistemas operacionais com suporte a multiprocessamento são a regra hoje em
dia, sendo que estamos atingindo inclusive o mercado de tablets.
Ambiente Paralelo
Em um ambiente multiprocessado, buscamos executar diversas aplicações ao

mesmo tempo, tirando proveito do conceito de sistema operacional multitarefa/
multiusuário.
Em um supermercado ou banco com apenas um caixa atendendo, ao colocar-
mos outros, o serviço fluirá melhor, já que existe independência entre as pessoas
que serão servidas. Em um ambiente paralelo, temos um desafio mais simples.
Imagine que sua tarefa é pegar um bloco de 1000 páginas e digitá-las. Propomos
duas soluções:
a) contrate o melhor digitador do mundo e entregue ao mesmo 1000 páginas,
e ele lhe devolverá o resultado em um arquivo;
b) divida o bloco de 1000 páginas em blocos de 10 páginas cada e entregue
a 100 digitadores medianos. Após cada um terminar a tarefa, junte todas as
partes em um grande arquivo.
107
Analisemos as soluções: Digamos que na opção “a” o digitador gaste 6 minu-

tos por página. No final, a tarefa será executada em 6 x 1000 = 6000 minutos, ou
100 horas.
Na opção “b”, considere que cada digitador gaste 20 minutos por página. Te-
remos então 10 x 20 = 200 minutos gastos por digitador. Como todo o trabalho
é feito ao mesmo tempo por pessoas diferentes, o tempo final gasto será de 200
minutos de digitação. Some a isso o tempo gasto para dividir as páginas em blo-
cos e juntar cada pedaço em um arquivo; suponha que gastemos 100 minutos
para isto. No final, teremos um gasto de 300 minutos, ou 5 horas. Muito menos
do que a primeira alternativa.
O fato de podermos dividir uma tarefa em partes e realizar isto em paralelo nos
leva a um ganho imenso. Isto é um raciocínio coletivo. Você não se lembra do dito
popular: “A união faz a força”?
Se migrarmos para o modelo computacional, o conjunto de máquinas que tra-
balham para realizar a tarefa de forma paralela, hoje, é realizado pelo mecanismo
denominado de cluster.
No cluster, temos a figura do nó coordenador que distribui as tarefas, os nós
de processamentos que todos rodam a mesma aplicação e o sistema de armaze-
namento onde os dados são gravados, sendo estes elementos ligados em rede.
Um cluster pode ser de alto desempenho, como no nosso exemplo, ou de alta
disponibilidade, quando todos fazem a mesma coisa.
O uso de sistema paralelo tem crescido muito no mercado. Em um primeiro
momento, era máquina montada para este fim em racks; hoje, podem ser clus-
ters de PCs. Um sistema operacional para um ambiente paralelo em cluster deve
ser capaz de lidar com a estrutura de rede e compartilhamento de recursos, mas
a “inteligência” de como as aplicações são paralelizadas está nas linguagens de
programação.
Diversos ambientes de “clusterização” têm sido desenvolvidos, a maioria em
Linux, sendo os mais conhecidos aqueles que fazem uso da arquitetura Beowulf.
Para testar os conceitos, visite o site <http://www.bccd.net>, onde poderá ser
usado o BCCD para teste do conceito.
VOCÊ O projeto de mapeamento de vida extraterreste SETI@

HOME (<http://setiathome.ssl.berkeley.edu/>) é um
SABIA? exemplo de uso de computação paralela.
108
Ambiente Distribuído
Enquanto os ambientes de rede focam no compartilhamento de hardware e

arquivos, ambientes distribuídos focam no compartilhamento de capacidade de
processamento e de memória. Com a consolidação das redes locais e da internet,
grande parte das aplicações passou a ser desenvolvida no chamado ambiente
cliente-servidor. Um exemplo é o cliente navegador internet, o servidor web e,
posteriormente, no chamado modelo de 3 camadas, em que temos a figura do
servidor de aplicação envolvido.
A tendência (entenda realidade) é termos a computação como serviço. Isto é
expresso pela premissa de computação em nuvem, onde nossa máquina mantém
apenas clientes de acesso e os serviços estão não na rede local, mas na internet.
Existem diversos sistemas operacionais desenvolvidos pensando nesta aborda-
gem, em que privilegiamos o compartilhamento de memoria e processamento
em métricas de segurança e desempenho.
Para conhecer mais sobre sistemas operacionais distribuídos,

SAIBA leia “Sistemas Distribuídos - Principios e Paradigmas”, de An-
MAIS drew Tanenbaum e Marteen Van Steen, da editora Prentice
Hall.
Em computação distribuída, enfrentamos todos os problemas tradicionais dos

sistemas operacionais em relação ao deadlock, comunicação entre processos e
compartilhamento de recursos. Entretanto, a resolução dos mesmos não é tão
simples, visto não termos apenas uma máquina, mas diversas máquinas interliga-
das em rede, executando nossas aplicações.
Em especial, devemos ter em mente aqui problemas relacionados em garantir
a replicação dos dados e que todas as réplicas estejam iguais, garantindo que se
uma máquina pare de executar outra assumirá seu papel, não deixando o cliente
saber que isto aconteceu. Deste modo, podemos invocar uma determinada apli-
cação sem saber em que máquina ele se encontra atualmente. O Java com RMI e
o modelo CORBA da OMG são elementos de suporte à computação distribuída,
bem como o net da Microsoft.
Neste tópico, vimos algumas características importantes dos ambientes para-
lelos, distribuídos e multiprocessados.
109
2.3.9 SEGURANÇA EM SISTEMAS OPERACIONAIS
Dreamstime
Figura 53 - Segurança
Hoje, vivemos um momento crucial na área de tecnologia da informação. De

um lado, a chamada convergência digital em que tudo vai para o computador; de
outro, a necessidade de garantir a segurança de todos esses novos ativos compu-
tacionais. Podemos dizer que o mundo é digital, mas que necessita estar seguro.
Ao estudarmos segurança da informação, especialmente através da ISO IEC
27002:2008, conseguimos caracterizar a visão de segurança com a tríade CIA
(Confidentiality, Integrity, Availability – confidencialidade, integridade e disponi-
bilidade). Na representação da política de segurança, a garantia destes itens se
estabelece a partir de uma visão de que temos vulnerabilidades, ameaças e riscos
de algo dar errado. O sistema operacional é o elemento chave na garantia de
grande parte dos elementos de segurança.
O PAPEL DO SISTEMA OPERACIONAL
Em primeiro lugar, destacamos que em um sistema computacional, normal-

mente, buscamos recuperar e armazenar informações em arquivos. Para tal, de-
vemos garantir confidencialidade, de modo que somente o dono dos dados con-
siga acessá-los. O mesmo vale para o processo em execução. Um processo não
deve interferir no outro e assim nos demais recursos computacionais.
Como recurso inicial, lembramos a necessidade de identificação-autenticação-
-autorização em sistemas multiusuários/multitarefa: o usuário deve apresentar
uma identidade, uma prova de que é quem diz ser, o que permite autenticar o
usuário; a partir daí, libera-se o acesso ao sistema e seus recursos, baseado nas au-
110
torizações de acesso que se concede. O sistema operacional controla o acesso a

14 Segregar seus recursos de hardware e internos, garantido nos diversos gerentes. Vejamos:
Separar. a) No gerente de processo: garantimos que um processo não consiga acessar
e alterar dados chaves do outro;
b) No gerente de memória: por meio do mecanismo de paginação, garanti-
15 Worm mos proteção entre os vários processos, bem como ao sistema operacional,
Código autorreplicante sem
visto a área em que ele não será mapeado para as demais aplicações, sendo
objetivo de ataque. acessível apenas via API do sistema operacional, tipicamente via mecanismo
de interrupção;
c) No gerente de arquivo: o controle de acesso aos arquivos, seja para leitu-
16 Applet ra, execução ou escrita, é feito com base nas permissões de cada usuário. O
controle varia de sistema a sistema: em alguns, como o Unix, temos o mo-
Pequeno aplicarivo Java.
delo que permite acesso baseado em usuário e grupo; em outros, como o
Windows, o mecanismo privilegia listas de controle de acesso (ACL), tam-
bém usáveis em Unix. Os arquivos são protegidos tanto de armazenamento
secundário, como em memória quando em cache do sistema operacional.
O ato de o sistema operacional proteger os arquivos em disco significa que
deve estar executando para proteger os recursos. Para tal, temos a garantia de que
apenas o administrador da máquina delegará permissões para um novo usuário;
contudo, se o HD de uma máquina com Windows ou Linux for removido e mon-
tado em outro computador, onde temos as permissões de administrador, todas
as informações em arquivos podem ser acessadas. Se você deseja manter a confi-
dencialidade, mesmo neste cenário, pode criptografar seu HD ou partições do HD:
a) O gerente I/O: garante o acesso exclusivo ao processo que está executando
a um determinado recurso;
b) O gerente de processo: garante a noção de máquina virtual onde um pro-
cesso tem tempo de execução, com respeito às prioridades de escalonamen-
to.
Além dos diversos recursos nativos dos gerentes, um elemento chave para se-
gurança são os registros de atividades, os logs.
SAIBA Para saber como realizar a criptografia de disco e partições

use o utilitário TrueCrypt e leia a sua documentação, dispo-
MAIS níveis em <http://www.truecrypt.org>.
111
LOGS NO SISTEMA OPERACIONAL
O sistema operacional, por executar todas as aplicações e por ter acesso a todo
o hardware, acaba sendo o ponto ideal para centralizar os logs de atividades. En-
contramos a possibilidade de registrar desde as chamadas de sistema para recur-
sos do sistema operacional que cada aplicação realizou, como registrar potenciais
tentativas de acesso indevidas a recursos, como arquivos ou áreas de memória,
bem como fornecer as aplicações de facilidades de coleta de logs, o mesmo para o
hardware. Um exemplo é armazenar informações de temperatura do processador
ou dados do smart de HD.
O sistema operacional armazena cada log em local devido, permitindo acesso
via aplicativos, como o visualizador de logs do Windows (acesso a partir do painel
de controle) ou mesmo lendo diretamente os arquivos, no caso do Linux (disponí-
veis em /var/log). A presença dos logs, que podem ser recolhidos e centralizados
em um loghost ou em uma aplicação SIEM (Security Information Event Manage-
ment), é essencial para o sistema de gerência de segurança de uma empresa.
FALHAS E VÍRUS
O sistema operacional, como todo software, pode apresentar falhas no seu de-
senvolvimento. Logo, uma falha (vulnerabilidade) pode ser usada para se obter
acesso indevido. Para evitar este problema, devemos estar atentos a como man-
ter o sistema operacional atualizado e às correções. Outro cuidado importante é
segregar14 contas de usuário, não concedendo permissão de adminstrador de for-
ma indevida e sem necessidade. Lembramos que, quando o administrador está
logado, para ele o sistema operacional se comporta como um sistema monousu-
ário, dando acesso a tudo.
Imagine um administrador, logado ao Windows e acessando a internet, sendo
vítima de um código malicioso que comprometa seu computador. Vai compro-
meter quaisquer recursos. Assim, a conta de administrador deve ser protegida e
usada apenas para princípios específicos.
Outros elementos de problemas são os vírus computacionais. Estes são centra-
dos em sistemas operacionais monousuários. Em sistemas multiusuários, como
Linux e baseados em Windows NT (XP, vista, 7), um vírus pode contaminar apenas
o perfil do usuário, não representado problemas para o sistema como um todo.
É claro que se você logar como administrador e acessar recursos com vírus ou
worm15, como programas ou sites na internet, podem acontecer problemas.
112
Java trabalha no conceito de máquina virtual, e ap-

FIQUE plets16 podem ser baixados da internet e rodar na sua
JVM. Essas execuções se darão com o usuário que está
ALERTA logado. Se for administrador/root, você pode ter gran-
des problemas de segurança.
Vimos que a segurança é um elemento essencial hoje em dia e que o sistema

operacional cumpre um papel imprescindível neste campo.
2 Conceitos de Sistemas Operacionais
113
Anotações:
Administração de sistemas operacionais
Pode-se dizer que os sistemas operacionais são softwares que gerenciam toda a atividade do
hardware de um computador visando tornar a utilização do computador mais eficiente e mais
conveniente.
Consistem em um conjunto de regras e funções bem estabelecidas, formalizadas e empre-
gadas para se obter um resultado em uma determinada área. São as regras de como se trabalha
e como se faz algo, deixando claro o que se faz com cada coisa.
Os sistemas operacionais vieram sendo aperfeiçoados longo do tempo. Atualmente estão
cada vez mais fáceis de usar, possuindo interfaces muito simples e bonitas.
Alguns sistemas são responsáveis pela gerência de muitos usuários, outros controlam dis-
positivos de hardware.
Após o estudo deste capítulo, você poderá ser capaz de:
a) definir o conceito de sistema operacional e conhecer sua evolução;
b) compreender separação de hardware/software e sua associação com máquina de Von
neumann;
c) conhecer as funções exercidas pelo sistema operacional assim como os tipos existentes;
d) definir os requisitos de hardware para sistemas operacionais;
e) conhecer o histórico e como se organizam os Sistemas Operacionais;
f) definir o sistema operacional multiplataforma: Unix;
g) conhecer o IBM PC e seus sistemas operacionais: do MS DOS ao WIN 7;
h) compreender o advento do Linux;
i) compreender a definição, compilação e interpretação de virtualização;
j) conhecer a arquitetura de sistemas operacionais.
Já que o sistema operacional é o programa mais importante do computador e que grande

parte da facilidade de uso do computador está relacionada a este, como profissional da área de
informática é essencial que você tenha os conhecimentos necessários do funcionamento dos
sistemas operacionais e assim poder auxiliar os usuários a desenvolver suas atividades.
sistemas operacionais
116
3.1 INSTALAÇÕES PARAMETRIZADAS DE SISTEMAS OPERACIONAIS

1 Swapping
Função do gerenciador
de memória que 3.1.1 IMPACTO DO SISTEMA OPERACIONAL NO DESEMPENHO
permite implementar
memória virtual com o
uso de armazenamento Quando pensamos na questão de desempenho em um sistema computacional,
secundário. normalmente nos lembramos do tipo de processador, da quantidade de memória,
do disco rígido, da placa de vídeo, ou seja, do hardware. Um aspecto que não é
lembrado de imediato é de que forma esses diversos recursos são gerenciados.
A gestão dos recursos de hardware cabe ao sistema operacional. Vamos a um
exercício prático que mostra a importância de uma parametrização adequada do
Imagine os seguintes desafios a serem realizados:
a) Levar 1000 folhas de papel de uma cidade a outra: para isso, você dispõe
de um envelope com capacidade para 500. Ao colocar apenas uma folha
por envelope, desperdiçaremos recursos, contudo, colocar 1000 folhas no
envelope não é possível;
b) Levar sacos de 100 kg de um prédio a outro, em uma distância de 50 m: para
isso, você dispõe de um carrinho de mão e de um guindaste. Se a quantida-
de de sacos for pequena, podemos usar o carrinho de mão, e, se for grande,
o guindaste será a melhor opção.
Em ambos, temos o problema e os recursos para resolvê-los. A forma que ge-
renciamos os recursos influencia muito no desempenho, em termos de tempo e
esforço na realização das tarefas. Não é diferente em computação. Se pensarmos
em ter um sistema computacional, focamos em ter não o hardware ou o software,
mas um sistema de informações gerenciais.
Em um SIG (Sistema de Informações Gerenciais), temos o foco no que faremos
com o produto dos sistemas computadorizados e quais são os resultados e pro-
blemas que o computador resolve. A informática deve ser tratada como instru-
mento de solução de problemas e não a computação como fim, em que somente
nos maravilhamos com a tecnologia que nos cerca. Se pensarmos na computa-
ção, devemos tê-la como um círculo virtuoso, em que aliamos tecnologia para
gerar novos produtos e soluções úteis, e não somente tecnologia, o que seria um
círculo vicioso.
Nesta abordagem, o foco dos profissionais das diversas áreas da computação
deve ser de aproveitar o máximo de recursos colocados à disposição para a so-
lução de problemas. Na maioria das vezes, temos o hardware, o computador e
a aplicação, que solucionará nosso problema, seja um mero editor de texto, um
navegador de internet ou um sistema de suporte vital em um centro médico. Se
3 Administração de sistemas operacionais
117
desejamos melhorar o desempenho do sistema, devemos investir na gestão dos

recursos que temos.
O sistema operacional cumpre esse papel. Devemos, então diante da vasta
gama de produtos no mercado, estar aptos a escolhermos uma solução em ter-
mos de sistema operacional que permitirá o máximo do desempenho com o con-
junto de aplicação e hardware disponíveis. As soluções são vastas, passando por
produtos de licença aberta e comercial, soluções para tempo real, que permitam
interatividade ao suporte de hardware embarcado e tantos outros cenários.
Imagine-se usando uma máquina que possui 1 GB de RAM, com um sistema
operacional que utilize cerca de 700 MB de memória para funcionar. Neste caso,
esse sistema foi uma escolha errada para o hardware em questão ou está mal pa-
rametrizado, gastando muitos recursos. Ou os requisitos de hardware para usá-lo
eram bem maiores que os que temos disponíveis; neste caso, o caminho passa
inevitavelmente pela troca do hardware ou pela escolha de um sistema operacio-
nal adequado para nossa plataforma e nossas demandas ou por sua customiza-
ção na instalação.
Não devemos usar um sistema operacional apenas por ser a última versão ou
por ser da moda. Existem diversos casos interessantes que demonstram que se o
hardware atende ao que desejo e ao sistema operacional também por que mudá-lo?
Por exemplo, hardwares antigos, como o processador Intel 486 e o sistema
operacional MS-DOS ou equivalente, ainda são fortemente usados, especialmen-
te na medicina, e funcionam muito bem.
Depois da escolha do sistema operacional, ou se já estiver instalado em uma
indústria ou empresa a qual damos suporte, nossa tarefa é customizar, parame-
trizando a instalação dele, tentando ajustar suas diversas características ao con-
texto em que estamos, seja ajustando seus módulos no gerente de processo,
escalonador, gerente de memória, gerente de arquivos e no suporte adequado
aos hardwares e periféricos instalados (papel do gerenciamento de I/O). Podemos
também escolher os serviços que serão executados no sistema operacional toda
vez que ele é carregado ao ligar o computador.
Se você tiver acesso ao código-fonte do sistema operacional, como no Linux,
BSD Unix ou Android, a tarefa de customização e parametrização permitirá ajustá-
-lo à sua realidade com um nível de perfeição bem maior do que usar um siste-
ma de código fechado, como o Microsoft Windows ou o Apple MacOS. Porém,
mesmo nesses sistemas, o fato de ajustarmos coisas como tamanho de memória
máxima suportada ou mesmo como o suporte a swapping1 será um diferencial
imenso em termos de desempenho e melhor uso do hardware.
É sempre um desafio ajustarmos itens tão próximos ao hardware como o sis-
tema operacional. Mas os ganhos vêm com ações como ajuste do kernel/núcleo
118
do Linux ou parametrização do Windows. Esses ganhos são imensos e justificam

o esforço, tenha certeza disso.
Vimos, neste tópico, que os desafios em informática são muitos. Que o com-
putador está presente para ajudar na solução e não para ser um novo problema.
Existe a necessidade de gerência de recursos de forma adequada. E o sistema
operacional possui essa responsabilidade, ou seja, deve ser adequadamente ajus-
tado e parametrizado na instalação e depois desta.
3.1.2 ESCOLHENDO A VERSÃO CORRETA DO SISTEMA OPERACIONAL:

Desktop, SERVER, EMBARCADO
Imagine se todos os veículos automotores fossem do mesmo tamanho: carro,

moto, van, ônibus. Não seria estranho? Poderíamos ter carros muito grandes para
poucas pessoas ou ônibus muito pequenos para muitas pessoas. A demanda por
serviços diferentes leva à necessidade de segmentação de produto. Na informáti-
ca, temos o mesmo cenário de demandas diferentes.
Existem no mercado diversos ambientes ou modelos computacionais. Cada
um possui particularidades e características únicas e precisamos levar em con-
ta ao usá-los. Devemos escolher qual sistema operacional empregaremos nesse
ambiente. Em especial, nos chama a atenção os ambientes de trabalho baseados
em desktop, notebooks, ambientes de servidores e embarcados. Vamos discutir,
neste tópico, os cuidados que devemos ter com esses ambientes e analisar alguns
aspectos de produtos, sistemas operacionais de licença fechada (Windows, prin-
cipalmente) e aberta (Linux).
O AMBIENTE Desktop
Este ambiente tem como característica-chave a interatividade do usuário em

um terminal com aplicações, normalmente por uma GUI (graphic user interface).
Como quesito-chave, o usuário deve ter a resposta o mais rápido possível quando
gerar uma ação, por exemplo, com o mouse. O cliente do sistema operacional é
o usuário final que deseja ter toda a atenção para a aplicação que está usando.
Como elemento de suporte a essa característica, temos que o sistema operacional
deve possuir em seu gerenciamento de processo um escalonador. Este permite
interromper a aplicação em uso (preemptivo) e realiza o tratamento dessa ação de
forma adequada.
O Windows 7 é parametrizado de forma que tenha esse foco. Mas por que di-
zemos parametrizado? A razão é que o Windows 7 é um dos diversos produtos
119
baseados no núcleo Windows NT, existindo também servidores, como o Windows

Server 2008, que na sua compilação serão otimizados para outras funcionalidades.
Se estamos usando o Linux, a forma em que o kernel do sistema operacional
foi compilado influencia muito. Diversas distribuições Linux são focadas no uso
como desktop (Ubuntu e Mint, por exemplo) e algumas em funcionar como servi-
dor (como Slackware e Debian).
Se desejarmos usar o Linux em um desktop, podemos escolher uma distribui-
ção que traz o kernel ajustado para esse papel ou compilar o kernel ajustando o
escalonador adequado. A figura a seguir mostra a seção de ajuste do kernel que
pode ser alterada. É simples, basta escolher o que deseja compilar e usar, o que
é mais fácil do que se habituar a uma nova distribuição. O mesmo vale se deseja-
mos usar o Linux como servidor.
Thiago Rocha (2012)
Figura 54 - Ajuste de kernel
Outro fator interessante no desktop é que nele raramente encontramos apli-

cações que funcionam como servidores de redes, como um servidor web ou de
DNS. Desta forma, se estamos usando um sistema operacional que tenha servi-
ços/servidores de rede ativos, devemos desabilitar esses serviços de modo a ter-
mos ganhos.
O AMBIENTE SERVIDOR
Enquanto que em um desktop o cliente do sistema operacional é o usuário

final, em um servidor o cliente é outro computador. Um computador desempe-
nhando a tarefa de servidor tem como função prover serviços a outras máquinas
ou usuários conectados via redes (via seu sistema operacional local), sendo suas
principais aplicações as de compartilhamento de arquivos e de rede computa-
cional, as quais executam localmente. Como exemplo temos o web server e o
gerenciador de banco de dados.
Requisitos-chaves que podem ser destacados são o gerenciamento de I/O (en-
trada e saída), que é de suma importância, e a gerência de memória, eficaz com
120
suporte a grandes quantidades de memória e múltiplos processadores. A dispo-

nibilidade de um escalonador que suporta múltiplas prioridades é requisito-cha-
ve ainda. Como elemento de segurança, o suporte à autenticação e autorização
baseado em serviço de diretório é elemento-chave nos dias atuais.
O sistema Windows, em sua versão Server 2008, atualmente R2, apresenta es-
sas características. Entretanto, não temos como ajustar o seu núcleo para o am-
biente que desejarmos, já que o código é fechado.
O Linux, atualmente em seu kernel na versão 3.x, apresenta todas as caracte-
rísticas-chave do Unix em relação a servidores, com a vantagem de podermos
customizar o seu código-fonte, escolhendo os parâmetros-chave para ele. Isso
também é válido para o BSD Unix.
Em ambos os sistemas operacionais, devemos estar atentos também à devida
configuração de cada serviço no servidor.
VOCÊ O Mac OS X, da Apple, consiste em um sistema BSD Unix

SABIA? adaptado e customizado.
O AMBIENTE EMBARCADO
Um sistema embarcado tem como característica sua utilização específica

para realizar uma tarefa em especial. O hardware possui configuração pequena
se comparado com nossas máquinas tradicionais. Tem processadores de baixo
desempenho e pouca memória e espaço de armazenamento. Outro elemento
consiste em que o sistema executa tarefas pré-programadas e não possui a fi-
gura do usuário interativo. Possui um sistema de gerenciamento de memória no
processador menos elaborado que os mecanismos tradicionais de proteção de
memória e paginação.
O uso da computação embarcada cresce a cada dia, estando presente desde
os clássicos sistemas de automação, como sistemas de alarme e acionamento,
entre outros, como eletrodomésticos, televisões e geladeiras, além de celulares.
Uma característica do sistema operacional é que não representa carga exces-
siva para o hardware diminuto e respeita as particularidades da aplicação a ser
automatizada. Muitas vezes, um sistema operacional monotarefa resolve o pro-
blema desejado. Como sistemas atuais, temos, em especial, o Linux, BSD Unix,
Windows Mobile e Android. O Windows Mobile consiste em uma implementação
diminuta do sistema Windows tradicional, sendo que o Linux, quando empre-
121
gado, tem apenas sua customização realizada para ter um kernel diminuto que
execute no hardware embarcado.
SISTEMA DE TEMPO REAL
Um sistema de tempo real possui como elemento-chave a necessidade de

atendimento instantâneo das requisições do usuário. Um exemplo é o ato de, em
um chão de fábrica, uma caldeira disparar um alarme e enviá-lo ao sistema opera-
cional. Ele deve tratar o evento imediatamente, deixando, se for o caso, a tarefa em
execução em segundo plano e atendendo a nova requisição de maior prioridade.
A solução para o problema consiste no emprego de um escalonador em tem-
po real, preemptivo e de múltiplas prioridades. O Windows e o Linux não conse-
guem atender esse requisito a princípio. Porém, o Linux, por ser de código fonte
aberto, tem sido bastante usado para essa atividade com a substituição de seu
módulo escalonador por um adequado. Outros exemplos são o RTOS e QNX, sis-
temas interessantes e bastante usados.
Do ponto de vista de customização, temos o ajuste das prioridades e tempos
do escalonador.
Vimos, neste tópico, que do mesmo modo que existem carros de tamanhos di-
ferentes que atendem diversas demandas, existem sistemas computacionais di-
ferentes que atendem diferentes demandas e expectativas. E, em cada um desses
ambientes, devemos estar atentos à devida customização e parametrização do
sistema operacional, de modo a tirar melhor proveito dos recursos disponíveis,
executando as atividades solicitadas a contento.
3.1.3 ESCOLHA DA VERSÃO CORRETA DO SISTEMA OPERACIONAL:

32 X 64
O sistema operacional é o elemento-chave na gerência do hardware. Logo,

devemos escolhê-lo ou ajustá-lo de acordo com o hardware que dispomos. Existe
uma gama muito variada de modelos de processadores no mercado, com recur-
sos diferentes e capacidades diferentes. Vamos, neste tópico, discutir a questão
de suporte a 32 e 64 bits. Vamos ao estudo.
A QUANTIDADE DE Bits DO PROCESSADOR
O que diferencia um processador de 64 bits de um de 128 ou de 256? O que

ganhamos com essas diferenças? Devo usar um sistema operacional específico
122
para cada um? São questões que causam aflição aos usuários atualmente. Procu-
raremos respondê-las.
Um processador é organizado internamente em ULA (Unidade de Lógica e
Aritmética), UC (Unidade de Controle) e possui áreas de trabalho denominadas
de registradores. Usamos em quase todos os processadores a arquitetura de Von
Neumman, que, para executarmos um programa, ele deve estar na memória prin-
cipal (memória de trabalho). A unidade de controle do processador busca ins-
truções e dados na memória principal e leva para a ULA da CPU, armazenando
valores nos diversos registradores. Para conectar a memória física ao processador,
usamos diversos barramentos (dados, controle, endereço). E então surge uma dú-
vida: quantos dados posso buscar ou colocar em memória por vez?
Essencialmente, o tamanho dos dados está relacionado à capacidade de onde
nós os tiramos e colocamos e à capacidade de onde armazenamos a informação
(os registradores da CPU).
Em uma máquina de 8 bits, os registradores são de 8 bits, e podemos, então,
a cada ciclo de transferência de dados da memória para a CPU, trazermos 8 bits,
ou um byte. Em uma máquina de 16 bits, temos registradores de 16 bits; em uma
máquina de 32 bits, registradores de 32 bits, e assim por diante. Qual o problema
que surge nisso? Nenhum a princípio.
Vamos compreender como é feita a busca e o envio de dados para memória.
Consideraremos, como exemplo, um processador de 8 bits. Para buscar uma
informação na memória e trazer para a CPU, o processador enviará no barra-
mento de endereço o endereço de memória e no barramento de controle o
comando READ (leitura) e obterá no barramento de dados 1 byte armazenado
na posição. Se desejarmos buscar 20 bytes, devemos repetir o ciclo 20 vezes. O
mesmo acontece se desejarmos escrever 20 bytes na memória que estão na CPU.
Vamos supor que temos um processador de 16 bits. Os ciclos são semelhantes ao
de 8 bits, mas, a cada vez, são transferidos 16 bits ou o dobro da informação. Logo,
se desejarmos transferir 20 bytes, teremos de repetir o processo 10 vezes. Para
um processador de 64 bits, o processo é o mesmo, mas transferimos 64 bits, ou 8
bytes por vez, e para transferirmos os 20 bytes propostos originalmente gastare-
mos apenas 3 ciclos.
Você pode notar que a ocupação dos barramentos é bem menor, assim como
o processo envolvido é mais rápido em processadores com maior capacidade de
armazenamento em registradores. Algo que você deve perceber é que, sempre
que usamos um processador de 64 bits, teremos transferências de dados nessa
taxa, somente se o software tiver sido escrito levando em conta a capacidade do
processador.
123
A explicação vem de que o primeiro processador para PC (o 8088, derivado

do 8086) era de 8 bits, e depois vieram os de 16 e 32 bits, e atualmente os 64 bits.
Contudo, por questão de suporte a aplicações legadas, um processador de 64 bits
implementa, além de suas características próprias, todo o suporte aos processa-
dores desenvolvidos antes. Existem muitos softwares desenvolvidos para 32 bits,
digamos que grande parte ainda. Logo, mesmo o recurso estando disponível, por
exemplo, 64 bits, vamos ficar sem usar ele.
Se pensarmos no sistema operacional como o responsável no desempenho
do hardware, devemos escolher aquele que tire o máximo proveito possível dele,
e a capacidade de transferência de dados para a memória é, sem dúvida, um dos
elementos mais importantes.
Na linha de produtos da Microsoft, o Windows 7 está disponível tanto na ver-
são de 32 bits (que pode ser instalada tanto no processador de 32 como no de
64 bits) como na versão de 64 bits (que não pode ser usada em processadores de
32 bits). Em relação ao Linux, diversas distribuições trazem o sistema operacional
compilado e otimizado para o suporte de 64 bits. Se a distribuição que você usa
não é uma dessas, podemos sempre recompilar o kernel, habilitando o suporte ao
seu processador e a 64 bits.
A especificação que usamos hoje no mercado é conhecida como X86_64, um
ajuste da arquitetura da Intel IA32 de 32 bits feita por sua principal concorrente, a
AMD. Existe a IA64 da Intel, presente no processador Itanium, por exemplo, mas
que não convenceu o mercado.
O que ressaltamos em relação ao sistema operacional também vale para as
aplicações que usamos na máquina. Ao empregar um sistema operacional de 64
bits (se a máquina suportar), é importante, para conseguir desempenho na aplica-
ção, que tenhamos a máquina compilada para 64 bits ou, no caso de uso de Java,
que a máquina Java em uso tenha sido compilada para 64 bits.
Vimos que tão importante quanto a escolha de um processador adequado é
a escolha de um sistema operacional que suporte todas as suas características.
Neste caso, o suporte a 32 ou 64 bits desempenha um papel-chave para obter o
máximo de desempenho do hardware, e tanto o Linux quanto o Windows apre-
sentam um bom suporte a 64 bits.
3.1.4 ESCOLHA DA VERSÃO CORRETA DO SISTEMA OPERACIONAL

MULTICORE, MULTIPROCESSADOR
Imagine que você comprou um novo conjunto de som estéreo com quatro
caixas de som e, por alguma razão, resolve usar apenas uma. Não é estranho? É
124
um investimento malfeito. O mesmo pode estar acontecendo com seu sistema

computacional.
Nos primórdios do IBM PC, ele foi desenhado para lidar com o máximo de 1 MB
de memória e o sistema operacional MS-DOS da mesma forma. Quando o proces-
sador Pentium começou a ser usado nos PCs, a memória tipicamente era de 32
MB de RAM, mas o sistema operacional MS DOS continuava suportando apenas
1 MB de RAM. Além disso, era preciso fazer “malabarismo” de programação para
usar a memória. Temos um caso de sistema operacional que não conseguia usar
todos os recursos (usar no sentido de gerenciá-los e distribuí-los às aplicações).
Hoje, existem processadores com diversos núcleos que são usados não somen-
te em servidores, (como era comum há alguns anos), mas também no desktop
ou em um tablet. Em servidores, temos a presença de diversos processadores, a
maioria das vezes com vários núcleos de processamento.
O gerenciamento do processador, como todo hardware, cabe ao sistema ope-
racional e deve ser planejado de forma adequada, evitando assim que utilizemos
apenas um núcleo de processamento de um quadricore ou apenas um processa-
dor em uma placa-mãe com dois. O elemento principal consiste no gerenciamen-
to de processo e de memória.
O gerenciamento de processo, por meio do escalonador, é quem aloca os pro-
cessos para execução. Se tivermos apenas um processador na máquina ou com ape-
nas um núcleo (vamos considerar um núcleo para cada processador, para facilitar
o entendimento), todos os processos são enfileirados para usar esse processador.
Se possuirmos mais de um processador, o sistema operacional pode alocar um
processo em cada um, cabendo ao programador contornar eventuais cenários
de deadlock (bloqueio devido à dependência mútua de recursos entre aplicações
diferentes), e cabendo ao sistema operacional o cuidado de tratar eventuais con-
flitos por acesso à memória.
No mercado, os sistemas operacionais Windows 7 e Windows 2008 suportam
mais de um processador (ou núcleo). Contudo, após uma quantidade específica,
necessita de licenciamento especial. É difícil interferir muito no gerenciamento
dos processadores pelo Windows, pois ele é devidamente parametrizado pelo
fornecedor e entregue apenas o código binário executável.
No Linux, podemos ajustar o código de modo a suportar mais de uma linha de
execução, seja mais de um processador, mais de um núcleo ou o suporte a HT do
Pentium 4.
Em qualquer sistema operacional, o cuidado que devemos ter é não habilitar
o gerenciamento dos recursos que não temos. Se ajustarmos o kernel do Linux
para tratar 16 processadores e a máquina que estamos usando tem somente uma
CPU, estaremos habilitando porções de código no kernel para tratar multiproces-
125
samento, o que acarretará tabelas internas maiores e a perda de desempenho. O

mesmo raciocínio e prática se aplicam ao suporte de memória muito grande ou
de arquivos extensos. Se usarmos objetos de tamanho tradicional, não devemos
habilitar essas características de maneira a evitar uma área de dados muito gran-
de do sistema operacional.
Vamos relembrar que a memória, como outros recursos, é endereçada por lista
e outras estruturas de dados que possuem índices; para endereçar pequenas áre-
as ou poucos recursos, podemos ter índices pequenos. Exemplo: para endereçar
64 Kb de memória, basta um índice de 16 bits – 216 permite endereçar a memória
em questão. Mas se temos 32 GB de RAM para endereçar, o índice será bem maior.
Contudo, se tivermos vários núcleos/processadores e não habilitarmos o su-
porte a eles, teremos apenas um em uso. O mesmo vale para memória extensa.
VIRTUALIZAÇÃO
Quando pensamos em vários processadores, o uso imediato, hoje em dia, tem

sido empregá-los para o suporte à virtualização, que pode ser feita tanto em ní-
vel de aplicação, como no Virtual Box ou VMware, quanto em nível de hardware,
como no Xen (acesse o site <http://xen.org>). Um requisito importante é que,
para a virtualização de hardware, o sistema operacional e o processador devem
suportar esse item.
Os processadores atuais da Intel e AMD possuem suporte nativo à virtualiza-
ção de hardware. O Windows 7 e o 2008, da mesma forma, proveem esse suporte.
O Linux suporta virtualização no kernel, mas esse elemento deve ser habilitado se
desejarmos utilizá-lo. Esse sistema operacional pode ser usado também como vir-
tualizador com o projeto KVM. Veja como em: <http://www.linux-kvm.org/page/
Main_Page>.
SMP
Quando temos mais de um processador físico na máquina, o hardware normal-

mente implementa o suporte a eles na placa-mãe via SMP (Simetrical Multi Proces-
sor). Mas, para que isso ocorra, o sistema operacional deve estar apto a suportar
SMP. Tanto o Linux quanto o Windows apresentam esse suporte.
Neste tópico, vimos que, se possuirmos mais de um núcleo de processador ou
processador em um computador, o sistema operacional deve suportá-los para
que possamos utilizá-los. Da mesma maneira quando desejarmos usar a virtua-
lização de hardware. O suporte a recursos estendidos, como muitas CPUs, me-
mória ou arquivos longos, deve ser tratado com cuidado, de modo que não os
126
habilitemos quando não for preciso, evitando índices muito grandes no sistema
operacional.
3.1.5 AÇÕES PRÉ-INSTALAÇÃO: DEFINIR E EXECUTAR

PARTICIONAMENTO DE DISCO; DEFINIR SISTEMA DE ARQUIVO PARA
INSTALAÇÃO DO SISTEMA OPERACIONAL, RAID, Swap
Se pensarmos em qualquer atividade que realizamos, temos diversas fases, em

especial: o antes, em que determinamos o que fazer e quando, o planejamento e
o ajuste de insumos para ela; o durante, quando realizamos; e o depois, quando
fazemos os ajustes de qualquer coisa que não tenha ficado adequada na execu-
ção e o encerramento da atividade.
Na instalação de um sistema computacional, seja software ou hardware e o
sistema operacional, esses princípios se aplicam.
Vamos discutir, neste tópico, o que devemos fazer antes de instalar o sistema
operacional.
Como instalá-lo? Muito fácil. Ligamos o computador, colocamos a mídia de ar-
mazenamento em que o sistema operacional se encontra (um DVD, por exemplo)
e, nas telas de instalação, sempre selecionamos next (ou próximo) e pronto. Se
tivermos sorte, talvez funcione. Como não devemos contar somente com a sorte,
precisamos ser mais metódicos no processo de instalação, principalmente definir
de forma clara onde instalaremos o sistema operacional antes de começar a tarefa.
O Software
O primeiro cuidado pode parecer óbvio, mas ter a cópia do sistema opera-
cional que vamos instalar – seja em CD, DVD ou outra mídia de armazenamen-
to – sem defeitos é importante. Lembramos que, se o sistema operacional for
comercial, temos de ter a licença do software. O ato de instalar uma versão de
software pirata em uma máquina de empresa equivale a entregar um produto
furtado a ela, sendo isso crime, passível de prisão e multa (para a empresa). Se for
um funcionário da empresa, normalmente pode ser dispensado por justa causa;
se for um terceiro, cabe a ação na justiça, bem como cancelamento do contrato
de prestação de serviços. Se a opção for software livre, como Linux ou BSD Unix,
não temos esse problema.
127
O DISCO
Devemos ter atenção à escolha do disco em que instalaremos o sistema ope-

racional. Se o hardware usar RAID, por segurança ou desempenho, teremos de
construir a estrutura de RAID de discos rígidos via controladora RAID antes de
iniciarmos a instalação.
Perceba que se for um RAID com Mirror, terminando de instalar o sistema ope-
racional, o RAID levará um tempo desnecessário para fazer a cópia dos dados.
O PARTICIONAMENTO
Escolhido o HD, devemos definir como ele será particionado e ficar atento à
organização de swapping. Na medida do possível, é interessante manter a parti-
ção de swap em discos físicos diferentes, para maximizar o uso do HD, deixando o
sistema em um disco físico e o swap em outro ou tendo mais de uma partição de
swap, uma em cada HD.
Se o sistema operacional suportar swap via arquivo (Windows), devemos, em
uma ação pós-instalação, ajustá-lo para ter o arquivo de swap presente em mais
de um HD ou partição. O uso de partição de swap colabora com o desempenho
por termos uma partição com organização especializada e sem fragmentação.
Feito o planejamento do uso de HDs e do particionamento, vamos executá-lo.
No Windows, essa atividade é feita pelo instalador (acesse o site <http://www.tec-
mundo.com.br/windows-7/3985-dicas-do-windows-7-como-particionar-o-disco-
-rigido-do-computador.htm> para entender melhor). Em algumas distribuições
Linux devemos usar o comando fdisk (o Windows também permite essa aborda-
gem). É importante que os dados do usuário estejam em uma partição criada para
manter o mínimo de organização e facilitar reinstalações de sistema operacional
sem perda dos dados do usuário.
Como ilustração do particionamento de disco, vamos utilizar o comando fdisk
em um Linux:
a) em primeiro lugar, devemos escolher o disco. Nesse caso, usaremos o disco
sda que, no nosso exemplo, já possui o Linux instalado. Primeiramente, exe-
cutamos o comando fdisk /dev/sda;
b) agora, podemos mostrar as partições correntes com o comando p. A seguir,
temos duas partições. Execute o comando d 1 e p e você verá que a primeira
partição foi apagada;
128
2 Journaling
Capacidade do sistema de
arquivos de manter um
registro (como um jornal)
de todas as alterações
as alterações feitas em
arquivos do disco de forma
a se recuperar de uma falha.
Thiago Rocha (2012)

Figura 55 - Fdisk – executando os comandos d, 1 e p
c) podemos nesse momento digitar d 2 e apagar a outra partição. Ao executar

p novamente, vemos a tela a seguir, que mostra o disco livre, sem partições;
Thiago Rocha (2012)
Figura 56 - Fdisk – disco livre, sem partições
d) como nosso HD é de 17,2 GB, criaremos no seu início uma partição para
swap de 3 GB e depois uma de 6 GB para o Linux. Digite n. Ao ser questiona-
do sobre o tipo, informe partição primária, número de partição 1, início no
setor 1 e com 3 GB de espaço. Digite p e verá a partição criada com o tipo
83, que é Linux. Contudo, queremos uma partição de swap, então devemos
alterar o seu tipo;
e) para alterar o tipo da partição, digite t e informe 82 (tipo swap – a lista de
opções é mostrada com L). Se você digitar p, verá a tela a seguir em que o
tipo foi alterado;
129
Thiago Rocha (2012)

Figura 57 - Fdisk – alterando o tipo de partição
f) você pode fazer o mesmo para criar outra partição. No final, ao sair, digite w
para gravar as alterações. Se tiver dúvidas, digite m para acessar o comando
help (ajuda).
O TIPO DO SISTEMA DE ARQUIVO
Realizado o particionamento, escolhemos qual sistema de arquivo emprega-

remos e como ele lidará com disco. No caso do Windows, a escolha recai no NTFS,
e não temos muita opção para parametrizá-lo.
No caso do Linux, existe uma vasta gama de opções de sistema de arquivo
incorporadas ao kernel. Em especial, temos o Ext nas versões 2, 3 e 4 (o Ext, como
solução de sistema de arquivo com journaling2 é normalmente uma boa opção).
Temos também o reiserfs e o Jfs, este último um produto derivado do sistema
operacional Unix da IBM, de alto desempenho, o AIX. Diversos sistemas de arqui-
vo podem conviver na mesma máquina sem problema.
Precisamos definir também o fator de alocação de disco na partição. Isto é,
qual o menor bloco de disco alocável. Uma escolha de 8 Kb significa que serão
alocados múltiplos de 8 Kb; para 32 Kb, serão múltiplos deste. Seria natural usar-
mos blocos longos, já que os arquivos são grandes. Porém, fique atento a isso de
modo a não cair na tentação, visto que essa abordagem pode levar a uma frag-
mentação excessiva do seu disco, alocando, por exemplo, um bloco de 100 Kb
para colocar um arquivo de 1 Kb; neste caso, 99 Kb seriam desperdiçados.
OUTRAS INFORMAÇÕES
Tenha certeza de ter anotado os parâmetros principais de configuração de

rede a colocar na nova máquina, seja endereço de IP, máscara, servidor de DNS,
domínio e, no caso de rede sem fio, as chaves devidas. Dependendo do sistema
operacional que está sendo instalado e da forma que a rede é administrada, será
130
necessário solicitar ao seu administrador a inserção da máquina na qual você aca-

bou de instalar na rede, por essa atividade requerer permissões de administrador.
Outro cuidado importante no planejamento é garantir que os drivers de dispo-
sitivo para os periféricos usados estejam disponíveis em mídia local, de maneira
que possamos ativá-los se o sistema operacional não tiver suporte nativo.
Um ambiente com eletricidade estável (uso de no-break, por exemplo) é reco-
mendável para que não tenhamos de começar a atividade do zero ao termos um
pico de energia.
Aprendemos, neste tópico, que a instalação de um sistema operacional, por
mais simples que pareça, deve ser precedida por um levantamento do que que-
remos da máquina onde será instalado, de modo que seja parametrizada e ade-
quada, focada sempre em segurança e desempenho.
3.1.6 AÇÕES PÓS-INSTALAÇÃO PARA OTIMIZAÇÃO DE DRIVER,

REMOÇÃO DE SERVIÇO
Você planejou a instalação de seu sistema operacional e depois de um bom

tempo o procedimento que estava realizando finalmente terminou. Na verdade,
o serviço não acabou, está apenas começando.
O software que acabou de instalar foi pensado para qualquer ambiente, sendo
que seu ambiente de trabalho certamente possui particularidades, como tipos de
placa-mãe, processador ou a finalidade de uso da máquina. Você deverá decidir
como ajustar o sistema operacional e obter o melhor desempenho e funciona-
mento possíveis. Neste tópico, discutiremos esses aspectos.
WINDOWS
Começaremos pelo Windows. O primeiro cuidado é garantir que todo o har-

dware esteja em funcionamento adequadamente e com os drivers dos disposi-
tivos corretos. Algumas vezes o Windows instala drivers genéricos que não são
muito eficientes.
A seguir, devemos ter certeza de aplicar as correções devidas (patchs) via atu-
alização do sistema operacional. Imagine que esse sistema foi criado há dois anos
e que você esteja instalando-o agora. Certamente existem atualizações que visam
melhorar o desempenho, suporte a hardware e, em especial, segurança.
Devemos estar atentos à instalação de uma solução de proteção para o siste-
ma operacional, seja um antivírus ou uma solução mais elaborada que incorpore
um firewall local.
131
O Painel de Controle (Control Panel) possui as ferramentas adequadas a essas

tarefas.
Após os ajustes, devemos então criar as contas locais dos usuários. Ligar o
computador à rede da empresa ou indústria, que pode requerer a ajuda do admi-
nistrador da rede, por demandar permissões.
No caso do Windows, devemos observar também a questão de swap. Se o swa-
pping usado for por arquivos, temos de espalhá-los em diversas partições, de for-
ma a maximizar o desempenho, preferencialmente em discos rígidos diferentes.
O cuidado seguinte é a remoção dos serviços não usados. O Windows, a exem-
plo de outros sistemas operacionais, instala e ativa, para nossa comodidade, di-
versos serviços que ficam rodando de fundo (background) no sistema, sendo que,
dependendo de nossa instalação, eles apenas gastam recursos, já que nunca serão
usados. Por exemplo: um facilitador de configuração de rede sem fio em uma má-
quina que nunca possuirá uma interface de rede sem fio. Por isso, desabilite os
serviços não utilizados. Isso pode ser feito pelo Painel de Controle via a execução
do services.msc. A figura a seguir mostra um exemplo do services.msc. Podemos
desabilitá-los e, se for o caso, deixar para inicialização manual, executando apenas
quando necessitarmos deles, e não sempre que ligamos o computador. Um ser-
viço executando significa mais um processo disputando CPU e memória, além de
um potencial ponto de falha se não estiver devidamente configurado e protegido.
Thiago Rocha (2012)
Figura 58 - Services.msc no Windows 7

132
LINUX
3 Boot loader
No Linux, dada sua característica de software aberto e livre, são muito maiores
Módulo responsável por
realizar a carga do sistema as possibilidades de ajustes e otimização em comparação ao Windows. Vamos
operacional em memória a discutir algumas possibilidades pós-instalação.
partir do disco.
O primeiro cuidado que devemos estar atentos é na configuração do boot
loader3, seja o LILO ou o GRUB, dependendo da distribuição, de forma a solicitar
senha se desejarmos “bootar” em modo monousuário ou usar outra imagem de
boot. Tal precaução nos permite tentar manter a premissa de confidencialidade
dos dados, evitando que um usuário mal intencionado faça o boot do sistema em
modo monousuário, por exemplo, e altere ou copie os arquivos da máquina.
O Linux pode ser inicializado em diversos modos:
a) em modo monousuário, sem suporte à rede;
b) em modo de rede multiusuário em texto;
c) em modo gráfico, com suporte a multiusuário e rede.
A escolha de qual modo desejamos usar pode ser informada no arquivo /etc/
inittab, sendo que a sintaxe e numeração dos modos podem variar em cada dis-
tribuição Linux. A figura a seguir mostra um exemplo do Slackware Linux. O ar-
quivo inittab é lido pelo programa init do Linux, primeira aplicação a executar
depois do kernel do sistema operacional ser carregado.
Thiago Rocha (2012)
Figura 59 - Slackware Linux /etc/inittab
Um cuidado que devemos ter é garantir que todos os periféricos foram devi-
damente detectados e configurados pelo kernel. Os comandos dmesg mostram
as últimas mensagens do sistema. No caso, as de boot estão entre elas; /var/log/
133
boot também apresenta tais mensagens. Se preferir, digite dmesg | more e terá
uma pausa em cada tela cheia de mensagens.
Assim observamos nas mensagens a detecção do processador, a quantidade
de memória e os periféricos, bem como características configuradas no kernel.
Thiago Rocha (2012)
Figura 60 - Dmesg no Linux
Se você desejar listar os dispositivos de hardware instalados para verificar se

algum não foi detectado, pode usar o comando lspci, o qual lista o barramento
PCI em busca de dispositivos, e o comando lsub, o qual lista o barramento USB
em busca de dispositivos.
A figura a seguir mostra saídas típicas desse comando, sendo que devemos lem-
brar que todos os devices listados em lspci e lsusb apresentam uma associação de
nome de dispositivo em /dev, que pode ser visto no processo de boot do dmesg.
Thiago Rocha (2012)
Figura 61 - Saída do lspci e lsub
Se um periférico não for reconhecido, devemos buscar o driver de dispositivo,

seja no kernel ou na internet, e compilá-lo para uso. Um driver pode ser nativo ao
134
kernel, compilado e carregado junto a este; ou binário (ou compilado como mó-
4 Clusterização dulo), e para tal se usa o insmod e lsmod para trabalhar estes.
Conjunto de máquinas
atuando como uma só, seja
para melhor desempenho
(HPC) ou segurança (HA). VOCÊ Com o advento do kernel 2.6 de suporte a versões, po-
demos usar drivers compilados para versões diferentes
SABIA? de kernel.
5 Scripts
Outro passo importante consiste em escolher um kernel otimizado para o pro-
Programa para
automatização de uma cessador de nossa máquina. Não existindo o mesmo disponível na distribuição
tarefa. que usamos, realizamos a compilação do kernel de forma a tirar vantagem das
características, em especial do processador em uso.
Precisamos, a seguir, proceder com a criação das contas locais no Linux para
os usuários e bloquear o login do administrador, root, seja via console ou via ssh
(neste caso, editamos o arquivo de configuracao /etc/ssh/sshd_config, retirando
permissão de login do root), e associar a máquina ao domínio da empresa com o
auxílio do administrador da rede.
O Linux possui o mito de ser difícil de usar por ser textual; entretanto, o Windo-
ws e outros sistemas operacionais também são textuais, trazendo uma GUI (gra-
phic user interface). O passo seguinte é configurar o X11 de modo que tenhamos a
resolução e o uso adequado da placa de vídeo, tirando o seu melhor desempenho.
Diferente do Windows, que foi criado para o usuário final e a facilidade de uso
(e ao longo do tempo tentou transformar-se em um servidor de rede), o Linux
nasceu como um servidor de rede, como uma variante do Unix.
Temos de remover todos os serviços que não estejam sendo usados ou que
não queremos utilizá-los no dia a dia. No Linux, essa atividade envolve desabilitar
os scripts de inicialização de serviço em /etc/init.d ou /etc/rc.d, dependendo da
distribuição e também das aplicações carregadas, como Daemons via TCP Wra-
ppers ou TCP, em /etc/inetd.conf ou /etc/xinetd.conf .
Entendemos, neste tópico, que, após o término da instalação de um sistema
operacional, devemos terminar os ajustes nele de modo a ter maior produtivida-
de, funcionalidade e uso racional de recursos.
3.1.7 ATIVAÇÃO DE SERVIÇOS
Vamos supor que você obteve sucesso na instalação do sistema operacional

e conseguiu concluir as ações pós-instalação realizando os ajustes básicos, otimi-
zando e removendo serviços não desejados. É chegada a hora de realizarmos a ati-
135
vação de novos serviços. Afinal, o sistema operacional é apenas a base sobre a qual
instalaremos nossas aplicações e algumas necessitam ser instaladas de imediato.
Para cada tipo de serviço que for instalar, tenha em mente que este deve ser
escolhido de forma minuciosa, sempre adequado ao sistema operacional instala-
do, hardware disponível e na segurança.
A segurança, algumas vezes, é deixada de lado, mas é muito importante. Em
algumas situações, é melhor não ter o serviço se ele não for seguro. Imagine um
sistema de internet banking sem segurança. Alguém vai querer usar um sistema
desses? Certamente que não.
Analisaremos alguns casos que, infelizmente, ocorrem muito: se colocarmos
um servidor de banco de dados no ar com senha padrão, podemos ter um proble-
ma com a confidencialidade dos dados lá colocados. Se não definirmos uma polí-
tica de backup da base de dados, teremos possíveis problemas com a integridade,
e se não pensarmos em uma política de espelhamento ou clusterização4 do servi-
dor de banco de dados, possuiremos problemas também com a disponibilidade.
Se pensarmos não em um, mas em dezenas de serviços instalados e executa-
dos em um computador, teremos um problema bem maior. Pequenos erros na
configuração de um ou outro serviço se somam e podem levar a uma instabilida-
de bem maior do que se houvesse a execução de apenas um serviço na máquina.
Tendo isso em mente, vamos pensar no que fazer.
No Windows é essencial que tenhamos antivírus e firewall ativados após a ins-
talação. O próprio sistema lembra ao usuário dessas pendências na barra de tare-
fas, como é visto na figura a seguir. Novos serviços podem ser controlados via o
comando services.msc ou no painel de controle após sua instalação.
Thiago Rocha (2012)
Figura 62 - Lembrete de pendências do Windows
No Linux, novos serviços podem ser ativados via scripts5 em /etc/rc.d e /etc/
init.d, dependendo da distribuição. Esses scripts podem ser criados automati-
camente pelo instalador do software ou algumas vezes devemos construí-los
manualmente.
136
Para aprender mais sobre o assunto, leia sobre a organização padronizada

6 Compilar para arquivos que as distribuições de Linux estão passando a adotar em <http://
Transformação de código-
www.linuxfoundation.org/collaborate/workgroups/lsb>.
fonte (linguagem de alto
nível) em executável pela Devemos estar atentos às permissões que daremos à nova tarefa a ser exe-
máquina (linguagem de cutada, tanto no Windows quanto no Linux , ou seja, com que permissões e que
baixo nível).
usuários ela executará. Veja a seguir uma história sobre a internet que ilustra bem
o problema.
7 Otimização
Personalizar um O ACESSO ROOT NO SENDMAIL E BIND

determinado produto de
forma tal que se obtenha
o melhor desempenho na O serviço de correio eletrônico consiste ainda hoje em um serviço essencial
execução de uma tarefa.
no dia a dia da internet. Durante um bom tempo, talvez tenha sido o principal
serviço. O software Sendmail foi a primeira aplicação que implementou a função
de servidor de correio eletrônico via protocolo SMTP (Simple Message Transport
Protocol).
Outro exemplo de serviço essencial na internet é o de resolução de nomes, em
que se mapeia um endereço IP, como 200.18.173.30, para um nome como ead.
senaigo.com.br ou, o contrário, um nome para o endereço IP. O ISC Bind foi, du-
rante um bom tempo, a solução primária na internet, mais usada para a tarefa de
DNS (e continua sendo). Qual o problema com os softwares Sendmail e ISC Bind
no passado?
Sempre foram excelentes aplicações, mas ambas, quando desenvolvidas,
foram pensadas para serem executadas como usuário root, o administrador no
Unix. Isso permitia a essas aplicações acesso e até alteração de qualquer recurso
no computador onde estavam instaladas. A princípio havia uma razão lógica para
o acesso root.
No caso do Sendmail, a ideia era de integrar os serviços de e-mails da internet
com o do sistema de mensagens do Unix, o qual empregava um arquivo por usu-
ário em /var/spool/mail para conter as mensagens do usuário. O usuário “garcia”,
por exemplo, teria o arquivo /var/spool/mail/garcia. A ideia é que esse arquivo
guardasse também as mensagens que vinham da internet via SMTP/Sendmail.
No caso, o uso dos arquivos de usuário necessitavam que o acesso fosse feito ou
via usuário ou administrador. Se avaliou por bem a execução via administrador.
Entretanto, qualquer problema no software Sendmail, no seu desenvolvimento,
podia levar um mero e-mail a comprometer o sistema como um todo. E isso não
aconteceu somente uma vez.
No ISC Bind, a escolha por executar como root não teve justificativa razoável,
apenas foi feito por ser mais fácil, por mais que fosse desnecessário, visto o Bind
ser meramente uma ferramenta que busca dados em uma árvore em memória.
137
Em ambos, falhas simples de programação levaram a grandes problemas em

empresas que as utilizavam. Hoje, ambas executam com usuários com permis-
sões limitadas e, apenas quando necessário, executam alguma tarefa como admi-
nistrador root. Logo, estão livres dessa falha.
No Windows, temos como exemplo clássico o IIS (Internet Information Service),
software que implementa servidor web e servidor ftp da Microsoft (também exe-
cutava como administrador). Isso representou muitos problemas para usuários.
Devemos estar atentos ao planejamento dos novos serviços que colocaremos no
ar, de modo que executem apenas com as permissões devidas, assim protegendo
os dados dos usuários e demais serviços da máquina.
Compreendemos, neste tópico, que nem todas as aplicações que necessita-
mos vêm incorporadas ao sistema operacional. Uma série de recursos deve ser
instalada posteriormente e configurada adequadamente, sendo uma das condi-
ções para uma instalação segura a atenção, evitando assim maiores problemas.
3.2 COMPILAÇÃO DE KERNEL
3.2.1 AJUSTES E VERSÕES DO KERNEL
Diversas formas podem ser usadas para realizarmos uma tarefa, mas certa-
mente nenhuma é mais eficiente do que escolher a ferramenta correta para re-
solver um problema.
Imagine você que tem como desafio realizar uma tarefa, como limpar o quintal
de sua casa. Você possui uma patrola, um alicate de unha, uma faca e uma enxada
para escolher. Sua escolha óbvia é a enxada, mas há um pequeno detalhe: a enxa-
da tem 1 metro de largura. Talvez ela seja muito grande. Se você possuísse uma
ferramenta de corte, poderia diminuir o tamanho dessa enxada. Isso certamente
permitiria empregar o instrumento de forma mais adequada à tarefa, se seu quin-
tal for pequeno. Em computação, no âmbito de sistemas operacionais, a escolha
do instrumento correto para realizar uma tarefa será fator de sucesso no uso e ge-
renciamento dos recursos. Algumas vezes, precisamos ajustar esse instrumento
que é nosso sistema operacional.
Se o sistema operacional for de código fechado, não temos muito o que fa-
zer, mas se ele for de código aberto, podemos mexer nesse código ou ao menos
compilá-lo6 de forma mais adequada. Vamos discutir, neste tópico, a otimiza-
ção7 do sistema operacional através de ajustes no seu código-fonte, algo que em
um primeiro momento pode assustar, pode parecer difícil, mas, como você verá,
consiste numa atividade simples e sem grandes riscos se executada com paciên-
138
cia, cuidado e persistência. Nosso trabalho estará centrado no kernel do Linux,

8 BSD UNIX mas muito do exposto se aplica ao BSD Unix8 ou mesmo ao Windows.
Que representa uma Versão
de Unix desenvolvida na
Universidade da Califórnia,
Campus de Berkeley. O LINUX
linguística como a única
aceitável.
O Linux, diferente de muitos outros sistemas operacionais, mantém um mode-
lo de desenvolvimento aberto, distribuído e bem peculiar. Vamos discutir como
funciona esse processo, bem como as versões do kernel do Linux existentes.
9 GNU
Antes de mais nada, lembre-se que o kernel do Linux consiste no Linux pro-
GNU Not Unix, projeto de priamente dito, sendo que o que usamos no dia a dia são as distribuições Linux
apoio e desenvolvimento
de software livre em nível que integram ao núcleo do sistema operacional um conjunto de facilidade de uso,
global.
bibliotecas e aplicativos focando na melhora da produtividade em uma determi-
nada área. Grande parte dessas ferramentas é originária do projeto GNU9, como o
GLIBC10, e outras tantas estão sobre licença de código GPL11 (GNU Public Licence).
10 GLIBC
O Linux teve início a partir de alterações feitas no sistema operacional acadê-
Implementação da LIBc mico Minix (baseado no Unix) feitas por Linus Torvalds.
(biblioteca básica usada
pelo Unix) feita pelo projeto Torvalds optou por um modelo tendo porções do código usáveis. Ele colocava
GNU.
essa porções em um servidor ftp aberto, para que outras pessoas pudessem fazer
donwload do software via e, se quisessem, postar colaborações com melhorias.
No início era um processo bem manual, bem diferente do emprego do GIT12, que
11 GPL permite um nível de colaboração quase sem intervenção humana realizando o
GNU Public License, principal commit de novas versões diariamente, empregado hoje, mas que já expressava o
licença de software livre modelo colaborativo de desenvolvimento.
usada hoje em dia.
O FreeBSD, mesmo sendo um sistema operacional de código aberto, tem em
torno de dez pessoas que podem inserir ou alterar código no sistema. O Linux, de-
12 GIT vido ao modelo de desenvolvimento, possui milhares de colaboradores, o que de
um lado leva ao crescimento mais rápido do sistema operacional, mas que pode
Software de controle de
versão de desenvolvimento significar instabilidade em algum momento.
usado pelo kernel do Linux.
SAIBA Para conhecer mais sobre o Minix, acesse o site da versão 3

MAIS do sistema em <http://www.minix3.org/>.
VERSÕES DO KERNEL
Até a versão 1.0 do kernel Linux , temos basicamente um sistema operacio-

nal que tentava ser executável e usável em computadores compatíveis com a ar-
139
quitetura IA32 da Intel da época, notavelmente o Intel 386 e depois o Intel 486.
Vamos discutir um pouco as características das diversas versões do kernel, que
podem ser encontradas em <http://www.kernel.org/pub/linux/kernel/ >.
a) Versão 0.x: embrião do que passamos a chamar de Linux. Essencialmente
temos o Minix ajustado e complementado com demais módulos do núcleo
do sistema operacional para ser usável e bibliotecas de apoio.
Começa, aqui, o uso de software do projeto GNU como elemento de suporte.
Exemplo: a GNU C Library (GLIBC).
Ao longo do tempo, essa prática levou ao emprego do termo GNU Linux
para denominar o Linux.
b) Versão 1.0: surge em um momento de popularização dos servidores web
na internet. Leva o Linux a virar, praticamente, padrão dos servidores web e
muito usado em outros serviços como e-mail e ftp.
Essa versão, contudo, era muito deficitária. Suportava apenas 256 processos
executando, tinha pouca memória e possuía um sistema de gerenciamento
de memória não muito eficiente. Entretanto, foi elemento-chave para po-
pularização do Linux. Essa versão começou a prática de nomes do kernel:
o primeiro dígito indica a versão; o segundo, se for par, uma versão de
produção, se ímpar, de desenvolvimento; os demais números níveis de
correção. Exemplo:
a) Linux 1.2.3 – versão 1.2 de produção nível de correção 3;
b) Linux 2.3.5.13 – versão 2.3 do kernel nível de correção 5.13.
Essa prática perdurou até o kernel 2.6, onde a árvore de desenvolvimento
e produção foram unificadas.
c) Versão 2.0: apresentou avanços marcantes como adoção de novos siste-
mas de arquivos, um sistema de gerenciamento de memória totalmente
novo, o suporte a vários processadores e processos em escala.
Marcou a consolidação do Linux como servidor confiável na internet e re-
cebe apoio de grandes fabricantes como IBM, HP, Oracle.
d) Versão 3.0: versão atual. Diferente das demais versões, a migração da ver-
são 2 para 3 não atendeu a mudanças de características técnicas no kernel,
somente a uma mudança de nomenclatura.
Torvalds observou que os nomes das versões estavam muito extensos, e
então foi feita a opção de migrar da versão 2.6.39 para 3.0. Essa modifica-
ção coincide com uma data histórica: 20 anos de existência do Linux (lan-
çado em 25/08/1991).
140
Qual versão de kernel usar? Bom, as versões 0.x e 1.x estão fora de uso, e as
versões 2.x e 3.x são as versões de produção. Para escolher uma versão, temos de
ficar atentos aos requisitos do software e hardware que usamos para decidir qual
deles usar.
Por que usarmos um kernel 2.4.x se o 2.6.x e o 3.x estão disponíveis em seu
ambiente?
A questão passa além da garantia que as aplicações que utilizamos sejam
compatíveis com esse kernel. Um exemplo é um software como Java Machine, que
precisa ser compatível, ou o sistema gerenciado de banco de dados (SGBD) ou a
presença de drivers de dispositivo para o hardware que temos disponível. Existe
também a questão de certificação de software.
Determinados fornecedores certificam seu software para uso em uma versão
de kernel. Exemplos disso são a IBM e a Oracle. Nesses casos, se não usarmos uma
versão de kernel, e muitas das vezes a distribuição Linux certificada, a empresa
fornecedora do software não dará suporte à sua aplicação.
Vimos, neste tópico, como é o modelo de desenvolvimento do Linux e as ca-
racterísticas das diversas versões do kernel, bem como os cuidados na escolha
dessas versões que utilizaremos em nosso ambiente de trabalho.
3.2.2 BAIXANDO O KERNEL E O PATCH
Se nosso objetivo é otimizar o kernel do Linux e termos maior funcionalidade e

desempenho, devemos, antes de tudo, ter o código-fonte do kernel disponível e
descompactado no disco para começarmos o trabalho.
Normalmente, ao instalarmos a distribuição Linux, temos a opção de instalar
o código-fonte do sistema operacional também, que será disponibilizado em /
usr/src/linux (diretório Linux é um link simbólico para o diretório corrente com o
kernel).
Se o código não for instalado, ou se desejarmos obter a versão atual do siste-
ma operacional, isto pode ser feito via ferramenta de atualização da distribuição
como apt-get (Debian), yum (Ubuntu) ou, de forma muito mais simples e prática,
simplesmente acessando o site do kernel em <http://www.kernel.org> e realizan-
do seu download.
A figura mostra a página onde podemos achar as diversas opções de kernel e
outras funções.
141
Thiago Rocha (2012)

Figura 63 - Versões de kernel - <www.kernel.org>
Podemos notar na figura que o Lastest Stable Kernel é 3.2.9 (na data da pesquisa)
e 3.3-rc6 (conhecido como release candidate: se não apresentar falhas, será o 3.3,
neste caso a sexta tentativa). Temos também as versões do 2.6. Em cada linha, você
pode baixar as fontes completas da versão ou um patch. Um patch consiste em
um arquivo com as alterações feitas em uma versão anterior. Se a versão que você
deseja não estiver nesse site, acesse <http://www.kernel.org/pub/linux/kernel/>.
Ao acessar o site do kernel, você pode obter preciosidades, como suas ver-
sões iniciais (<http://www.kernel.org/pub/linux/kernel/Historic/>) e um link para
a mensagem de Torvalds ao lançar o Linux (<http://groups.google.com/group/
comp.os.minix/msg/b813d52cbc5a044b>).
Os arquivos que fazemos o download estão empacotados for formato .tar e
comprimidos em bz2. Devemos descomprimi-los e desempacotá-los para uso.
DESCOMPRIMINDO O ARQUIVO
Digamos que você acaba de baixar o arquivo linux-3.2.9.tar.bz2, que é a última

versão na imagem anterior. Para descomprimi-lo, execute:
bunzip2 linux-3.2.9.tar.bz2
Ao fazer isso, você obterá o arquivo linux-3.2.9.tar (veja isso com um ls – l).
Atualmente, empregamos o formato bz2, mas anteriormente foi usado o gz.
Nada impede de no futuro termos um compressor mais eficaz e o formato mudar;
caso isso ocorra, estará informado na página.
142
DESCOMPACTANDO O KERNEL
O formato .tar foi desenvolvido há muito tempo para realizarmos cópias de

árvores de diretórios em unidade de backup, em especial em fitas.
O formato bz2 é um de compreensão de dados, enquanto o .tar apenas gera
um arquivo imagem dos diretórios sem comprimi-los.
O kernel do Linux deveria estar no diretório /usr/src por questão de organização.
Vamos movê-lo para lá com comando:
mv linux-3.2.9.tar /usr/src
Digite:
cd /usr/src
Para ir ao diretório e descompactar o arquivo com o comando .tar:
tar –xvf linux-3.2.9.tar
Os parâmetros são x (extrair), v (verbose – mostrar na tela) e f (file – nome do
arquivo).
A saída do comando será semelhante à figura seguinte, em que vemos os ar-
quivos sendo desempacotados:
Thiago Rocha (2012)
Figura 64 - Saída do tar –xvf linux-3.2.9.tar
Se você der o comando ls – l (listar arquivos), verá o diretório criado e outros.

A figura a seguir mostra um exemplo:
143
Thiago Rocha
Figura 65 - Arquivos em /usr/src
Na figura anterior, você notará que o diretório Linux é um link simbólico para
o diretório linux-2.6.33.4.
Você pode mudar esse link simbólico para o kernel que instalamos, com o co-
mando:
rm linux
ln –s linux-3.2.9 linux
O rm remove o link atual, o ln cria um novo. Ao executar ls novamente, verá
que o diretório Linux está apontando para o nosso kernel desempacotado. Tente
repetir esse passo e terá algo semelhante à figura a seguir.
Thiago Rocha
Figura 66 - Link para diretório ajustado
PATCH
Se você preferir, pode baixar apenas um arquivo com as diferenças que foram
incorporadas ao kernel que já possui. Chamamos isso de arquivo de patch, ou de
correção. O formato do arquivo é bz2 da mesma forma, mas não está empacota-
do, consistindo em um arquivo para ser usado pelo aplicativo patch do Unix.
Assumindo a figura anterior, em que temos nosso kernel recém-instalado, po-
demos aplicar as correções para a próxima release candidate (no caso, seria o 3.3-
rc6, conforme a figura 9). Vamos aplicar um patch para ele. Para tanto:
a) se tiver saído do diretório /usr/src, volte para lá com o comando cd;
b) acesse o site do kernel em <http://www.kernel.org> e busque o arquivo da
nova versão (linux-3.3-rc6.tar). Você pode baixar esse código ou o arquivo de
patch. Clique na página principal no link patch em frente à versão 3.3-rc6. O
arquivo patch-3.3-rc6.bz2 será baixado;
c) agora descomprima-o com o comando bunzip2 patch-3.3-rc6.bz2;
144
d) finalmente, aplique o patch ao kernel com o comando:

cd linux-3.2.9
cat ../patch-3.3-rc6 | patch –p1
Isso aplicará ao arquivo as diferenças no código-fonte, com efeito semelhan-

te ao de um novo arquivo baixado. A figura seguinte apresenta uma saída do
nosso comando. O comando patch possui diversos parâmetros que podem
ser vistos com o comando man patch.
Thiago Rocha (2012)

Figura 67 - Aplicação de patch
Aprendemos, neste tópico, como obter a última versão do kernel ou outra

que você queira, bem como arquivos de patch. Compreendemos também como
desempacotar e descomprimir esses arquivos. Se você tiver dúvidas sobre como
usar o comando, sempre pode usar o comando man (exemplo: man ls) que pode-
mos achar no manual do comando.
3.2.3 AMBIENTE DE COMPILAÇÃO E AJUSTES
Um amigo seu resolveu pescar. Acordou cedo, pegou todos os seus apetre-
chos e foi ao seu local de pesca preferido. Chegando lá descobre que esqueceu a
vara de pescar. Provavelmente, será possível pescar usando um método que não
precise da vara, mas não será tão eficaz.
Para a tarefa de compilar e ajustar nosso kernel é preciso também de uma série
de ferramentas, como o compilador e as ferramentas de geração de scripts. Va-
mos, neste tópico, abordar como fazer isso.
Um passo inicial para alterar e customizar de forma otimizada sua instalação
Linux consiste em baixar o código completo do kernel ou patch e aplicá-lo. Como
você já sabe, após essa atividade, devemos proceder com a parametrização do
kernel, mas antes devemos definir os requisitos mínimos de compilação do kernel.
145
O AMBIENTE DE COMPILAÇÃO
O código-fonte do kernel do Linux, como qualquer outro software que deseja-

mos compilar, requer um ambiente mínimo. O kernel basicamente é escrito nas
linguagens C e uma pequena parcela em Assembly da arquitetura que queremos
usar. Para a compilação do kernel, necessitaremos de uma série de ferramentas.
Como passo inicial, vamos entrar no diretório do kernel e listar os arquivos lá
existentes.
No comando cd linux, entraremos no diretório e o ls listará os arquivos.
A seguir, você encontrará a saída do aplicativo. O arquivo README contém
uma série de instruções úteis e também nos diz onde encontraremos a listagem
de requisitos de software para compilar o kernel.
root@slvm:/usr/src/linux# ls
COPYING Documentation/ Kconfig Makefile REPORTING-BUGS block/ drivers/ fs/
Odirlei Batista (2012)

init/ kernel/ mm/ samples/ security/ tools/ virt/
CREDITS Kbuild MAINTAINERS README arch/ crypto/ firmware/
include/ ipc/ lib/ net/ scripts/ sound/ usr/
root@slvm:/usr/src/linux#
Figura 68 - Arquivo README
Você poderá usar o comando ‘more README’ para ler esse arquivo. Ao lê-lo,
vai se deparar com a informação de que a listagem de software necessária está
no arquivo Changes, dentro de Documentation. Visualize esse arquivo com more
Documentation/Changes e encontrará a seguinte listagem:
Current Minimal Requirements

....<trecho recortado>
o Gnu C 3.2 # gcc --version
o Gnu make 3.80 # make --version
o binutils 2.12 # ld -v
o util-linux 2.10o #fdformat --version
o module-init-tools 0.9.10 #depmod -V
o e2fsprogs 1.41.4 #e2fsck -V
o jfsutils 1.1.3 # fsck.jfs -V
o reiserfsprogs 3.6.3 # reiserfsck -V
o xfsprogs 2.6.0 # xfs_db -V
o squashfs-tools 4.0 # mksquashfs -version
o btrfs-progs 0.18 # btrfsck
o pcmciautils 004 # pppd --version
o quota-tools 3.09 # quota -V
o PPP 2.4.0 #pppd --version
o isdn4k-utils 3.1pre1 # isdnctrl 2>1|grep version
o nfs-utils 1.0.5 # showmount --version
o procps 3.2.0 # ps --version
o oprofile 0.9 # oprofiled --version
o udev 081 # udevd --version
o grub 0.93 # grub --version || grub-install--version

o mcelog 0.6 # mcelog --version
o iptables 1.4.2 # iptables -V
....<final do arquivo recortado>
Figura 69 - Arquivo Changes

146
Para saber mais sobre o kernel que está usando, leia a documentação encon-
trada no diretório Documentation que pode lhe ser muito útil.
Na frente de cada ferramenta, está listada a versão do software necessária para
a compilação (mínima) e o comando para descobrir qual versão você está usan-
do. O restante do arquivo informa como a aplicação será usada e onde pode ser
obtida se não tiver ela instalada em seu Linux.
Vamos realizar um teste. Verifique a versão do GCC que você possui.
root@slvm:/usr/src/linux/Documentation# gcc --version

gcc (GCC) 4.4.4
Copyright (C) 2010 Free Software Fondation, Inc.
This is free software; see the source for copying conditions.There is

NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
root@slvm:/usr/src/linux/Documentation#
Figura 70 - Versão do software
Na máquina usada para desenvolvimento dessa atividade (distribuição Sla-

ckware 13.37 executando dentro do VirtualBox), existe a versão 4.4.4 do GCC, o
que é suficiente para compilar nosso kernel no caso o Linux 3.2.9. Dependendo da
distribuição que estiver usando, a versão será outra ou pode acontecer de obter
como resultado o descrito a seguir.
Thiago Rocha
root@slvm:/usr/src/linux/Documentation# gcc -- version
-bash: gcc: command not found
Figura 71 - Versão do software
Neste caso, o GCC não está instalado na máquina ou não temos um caminho
para ele e devemos solucionar o problema antes de prosseguir com a compilação
do kernel.
Além do GCC e do MAKE, outro elemento muito importante é o montador
Assembly, visto que uma pequena parcela do código do kernel está escrita em
Assembly. O GLIBC (GNC LibC) é outro elemento determinante, já que essas bi-
bliotecas da linguagem C serão usadas em escala. As demais ferramentas da lista-
gem tem caráter acessório, sendo que talvez consiga compilar o kernel sem elas.
Contudo, o ideal é ter o ambiente propício para evitar falhas.
Normalmente, essas aplicações estão inclusas no pacote de desenvolvimento
da distribuição, sendo que algumas vezes sua instalação é opcional, estando dis-
ponível no DVD de instalação. Em algumas distribuições você terá de baixar tanto
o código-fonte como todo o ambiente de problema. No momento que está se
habituando ao sistema operacional Linux, escolha uma distribuição que já tenha
o ambiente de desenvolvimento.
147
Um ponto não citado e que necessita ser lembrado é que precisamos de es-
paço em disco livre se queremos compilar nosso kernel. O comando df mostra o
espaço ocupado e livre na partição. Se não tivermos espaço livre, não poderemos
desempacotar nosso fonte nem compilar o kernel. Fique atento a isso.
Note que todas as observações sobre versão de software necessárias para a
compilação, bem como a própria lista de software, consiste em um requisito da
versão de kernel que lidamos. O compilador C (GCC) e as LIB C (GLIBC) são os
elementos primordiais no processo. Se estiverem compatíveis, provavelmente o
processo de compilação funcionará, mas você pode ter um código instável no
final.
Aprendemos neste tópico que, ao compilar e ajustar nosso kernel, além baixá-
-lo da internet, devemos ter certeza de que temos o ambiente de desenvolvimen-
to e compilação adequados.
3.2.4 ORGANIZAÇÃO DO KERNEL – PARTE 1
Se você deseja realizar qualquer tarefa de modo adequado, deve entender

como as partes envolvidas funcionam. De nada adianta ensinar uma criança a
decorar a tabuada de multiplicar e de dividir, se ela não sabe realizar somas e
subtrações.
Precisamos aprender do simples para o complexo, para evoluirmos. Em nossa
tarefa, de otimizar o kernel Linux, precisamos ver como as coisas estão organiza-
das antes de embarcarmos nessa aventura
Lembramos que o kernel do Linux consiste no sistema operacional Linux em si.
O restante do Linux são acessórios que nos permitem utilizar esse kernel como
um sistema operacional pleno. Neste tópico, relembraremos a organização de um
sistema operacional e tratar a organização da árvore de código do kernel Linux.
O SISTEMA OPERACIONAL
Um sistema operacional pode ser visto como elemento de implementação da

gerência.
Na figura a seguir, vemos as funções básicas de um computador, em termos
de processador (onde as atividades são executadas), canais de entrada e saída,
armazenamento principal, memória e armazenamento secundário, em mídia per-
manente.
148
Gerente de
memória
Memória
Gerente de I/O Gerente de I/O

Entrada Saída
Processamento Gerente de
Processos
Thiago Rocha (2012)

Arquivos
Gerente de
arquivos
Figura 72 - Funções de um sistema operacional (original do CSO_003)
O sistema operacional está organizado no gerenciador das tarefas em execução,

onde implementa a visão de um ou mais processos em execução. Essa função está
centrada no gerenciamento de processos e no módulo de escalonamento. Temos a
função de gerenciar a memória principal e a devida proteção de memória, de forma
que um processo não interfira no outro, e nos dê também noção da memória virtu-
al. Essa função se encontra centrada no gerenciamento de memória.
O gerenciamento das mídias de armazenamento permanente, com a imple-
mentação de abstração de arquivos, diretórios, proteção e permissões de arqui-
vos se encontra centrada no gerenciamento de arquivos. E, finalmente, o geren-
ciamento dos dispositivos periféricos de entrada e saída que recebem e fornecem
dados ao processador está no gerenciamento de I/O.
Os diversos módulos interagem para prover funcionalidades para o usuário do
sistema operacional, podendo a implementação ser realizada de forma modular
ou monolítica desse software. Na primeira, existe a modularização clara e devidas
passagens de parâmetros entre os módulos, na segunda os parâmetros estão su-
bentendidos e muitas das vezes são variáveis globais.
O LINUX
O Linux como núcleo de sistema operacional desempenha as tarefas listadas

anteriormente.
Devemos ressaltar uma característica importante dele: consiste em um sistema
multiplataforma, suportando tanto a arquitetura x86 de computadores PCs como
149
outras implementações indo do processador ARM em embarcados, ao mainframe

no sistema 390 da IBM.
Essa característica requer que o código-fonte do Linux para todas as platafor-
mas esteja disponível no mesmo arquivo de kernel tar.bz2. Ou seja, ao acessarmos
o site < www.kernel.org > e obtermos o arquivo-fonte do kernel, este pode ser
compilado em qualquer plataforma que o suporte, além de compilação cruzada
para outra plataforma.
Podemos compilar um software para uma plataforma A em um B, exemplo com-
pilador um código para o PowerPC em um X86 mesmo a plataforma X86 não supor-
tando as instruções, basta termos um compilador que gere o código executável.
A ÁRVORE DE CÓDIGOS
Ao entrarmos no diretório do código-fonte (considerando o kernel 3.2.9), no

primeiro nível podemos notar a organização na figura a seguir.
Podemos obter a visão em árvore de diretórios com o comando tree, no caso
usamos tree –L 1 linux-3.2.9 (onde linux-3.2.9 é o diretório) para obter o que cons-
ta na figura seguinte.
Esse comando pode ser bastante útil a você.
Linux-3.2.9
|-- COPYING
|-- CREDITS
|-- Documentation
|-- Kbuild
|-- Kconfig
|-- MAINTAINERS
|-- Makefile
|-- README
|-- REPORTING-BUGS
|-- arch
|-- block
|-- crypto
|-- drivers
|-- firmware
|-- fs
|-- include
|-- init
|-- ipc
|-- kernel
|-- lib
|-- mm
|-- net
|-- samples
|-- scripts
|-- security
|-- sound
|-- tools
|-- usr
`--virt
Figura 73 - Árvore de códigos

150
Primeiro os arquivos presentes nos diretórios:

a) COPYING: possui informações de copyright do kernel, no caso é licenciado
sobre a licença GNU GPL;
b) CREDITS: créditos aos autores |-- Documentation;
c) MAINTAINERS: lista dos responsáveis por manter cada parte do kernel e
como submeter uma correção ao kernel;
d) REPORTING-BUGS: descrição de como enviar um bug que foi encontrado;
e) Kbuild, Kconfig: arquivos de auxílio à configuração do kernel;
f) Makefile: arquivo para aplicativo make compilar o kernel;
g) README: informações gerais sobre o kernel e cuidados.
Os diretórios listados na figura anterior refletem a organização do kernel em
seus diversos gerentes, arquivos e módulo básicos de suporte:
a) Documentation: esse diretório contém a documentação dos diversos mó-
dulos do kernel e como estão organizados. Consiste numa ferramenta útil
para resolver eventuais problemas junto ao arquivo README. Tente encon-
trar a documentação de como é feito o processo de boot no PC. Encontrou?
Está em Documentation/x86/boot.txt, da mesma forma que existem diver-
sos outros arquivos que lhe podem ser úteis;
b) arch: o diretório arch contém código dependente de plataforma. Imagine
um processador A e um processador B que em suas plataforma cada uma
lida com memória de forma diferenciada. No diretório de gerenciamento
de memória, estará o código de gerenciamento de memória que interagem
com o restante do kernel. Nesse diretório estará o código que irá interagir
com o hardware em cada plataforma.
Encontramos diversos módulos. Um software de boot para cada plataforma.
Vamos examinar o software de boot do x86, seguindo os seguintes passos:
Passo 1: Digite tree –L1 arch que vai lhe mostrar uma árvore de diretório de
um nível.
Você verá uma saída parecida com a figura a seguir, variando como e onde po-
demos ver a lista de arquiteturas suportadas. Como pode ver é uma lista razoável,
entre elas o x86 marcado em vermelho:
151
arch/
|-- Kconfig
|-- alpha
|-- arm
|-- avr32
|-- blackfin
|-- cris
|-- frv
|-- h8300
|-- hexagon
|-- ia64
|-- m32r
|-- m68k
|-- microblaze
|-- mips
|-- mn10300
|-- openrisc
|-- parisc
|-- powerpc
|-- s390
|-- score
|-- sh
|-- sparc
|-- tile

|-- um
|-- unicore32
|-- x86
`-- xtensa
Figura 74 - Árvore de diretório de um nível
Passo 2: Vá para o diretório x86/boot com cd x86/boot e liste os arquivos pre-

sentes.
Esses arquivos são módulos básicos de boot do Linux para a plataforma x86,
a qual seu computador pertence. Os arquivos estão em C e poucos em assembly
(extensão .S), mas mesmo os .c não são portáveis para outras plataformas por
dependerem de requisitos de hardware da arquitetura x86.
Makefile bioscall.S cmdline.c copy.S ctype.h header.S mca.c

mtools.conf.in printf.c string.c version.c video-mode.c video.c
a20.c bitops.h code16gcc.h cpu.c early_serial_console.c
install.sh memory.c
pm.c regs.c tools/ vesa.h video-vesa.c video.h

apm.c boot.h compressed/ cpucheck.c edd.c main.c
mkcpustr.c
pmjump.S setup.ld tty.c video-bios.c video-vga.c
Figura 75 - Módulos básico de boot do Linux para a plataforma x86
Veja o conteúdo dos arquivos e você encontrará coisas interessantes.

Volte ao diretório arch com um cd .. ou cd /usr/src/linux/arch e leia os demais
arquivos.
152
Esses arquivos estão presentes, divididos por diretório, o software para cada
13 Inode arquitetura suportada pelo Linux.
Índice de descritores de Neste tópico, compreendemos a organização dos arquivos em primeiro nível
blocos usados em disco
empregado no Unix do kernel: o diretório arch, vimos um exemplo visitando onde encontramos o boo-
compilado - transformado tloader do Linux para IBM PC. Da próxima vez que ver o computador bootando,
de código-fonte (linguagem
de alto nível) para você saberá que é aquele código executando. Aprendemos também onde se en-
executável pelo hardware
(linguagem de baixo nível).
contra a documentação do kernel.
3.2.5 ORGANIZAÇÃO DO KERNEL – PARTE 2
Você já conhece os arquivos-chave na raiz do kernel do Linux, bem como o di-

retório arch. Necessitamos entender o que tem em cada um dos demais diretórios
e como estão organizados os device drivers.
Observando as informações a seguir, entenderemos os diretórios em negrito,
que não conhecemos ainda no kernel.
Linux-3.2.9
|-- COPYING
|-- CREDITS
|-- Documentation
|-- Kbuild
|-- Kconfig
|-- MAINTAINERS
|-- Makefile
|-- README
|-- REPORTING-BUGS
|-- arch
|-- block
|-- crypto
|-- drivers
|-- firmware
|-- fs
|-- include
|-- init
|-- ipc
|-- kernel
|-- lib
|-- mm
|-- net
|-- samples
|-- scripts
|-- security
|-- sound
|-- tools
|-- usr
`--virt
Figura 76 - Diretórios
153
Os diretórios que aparecem na figura acima são:

a) mm: este diretório contém o código do memory management, ou seja, do
gerenciador de memória do Linux, entre no diretório e de uma olhada nos
arquivos disponíveis;
b) net: este diretório contém o código do suporte a rede do Linux. Entre no
diretório e digite um ls, você obterá uma listagem que mostra itens impor-
tantes como o tcp/ip (diretórios ipv4 e ipv6) e ethernet (diretório ethernet)
alem do wiffi e outros;
c) fs: diretório que contém o suporte a gerenciamento de arquivos. Encontra-
remos no suporte a estrutura de inode13 de indexação de disco, organizado
por diretório e o código-fonte de cada sistema de arquivo suportado pelo
Linux. Devemos entender que a diferenciação do vfs dado por esse “estilo”
de organização de arquivos em disco é a parte física, fornecida pela estrutura
de superbloco e inode, semelhante ao Unix;
d) block: este diretório contém o código de suporte a drivers de bloco, neces-
sário para, por exemplo, discos rígidos e cds;
e) crypto: ao longo do tempo, cada vez mais, tem sido necessário o supor-
te à criptografia para garantir confidencialidade dos dados. Atualmente é
comum implementarmos partições de disco criptografadas. Esse diretório
contém o código dos algoritmos de criptografia mais comuns usados no
mercado, como aes, blowfish e 3des, de forma tal que possamos usar essas
bibliotecas em modo kernel para suporte ao sistema operacional em seus
diversos módulos;
f) firmware: o diretório contém o código de suporte ao firmware de dispo-
sitivos que necessitem da sua carga para funcionar. Podemos encontrar o
firmware se disponível para uma série de dispositivos. Novos dispositivos
podem ter o firmware adicionado;
g) init: após o kernel do sistema operacional ser carregado em memória e ini-
cializado, sua última ação é tentar executar o comando init. Esse diretório
contém código para tal, em especial, observe o final do arquivo main.c no
diretório transcrito a seguir, o kernel tenta encontrar o utilitário init em locais
diferentes já que, infelizmente, nem todas as distribuições seguem o padrão
LSB (Linux Standard Base) de organização de arquivo. No caso, o run_init_
process tenta executar a aplicação. Se as três tentativas de executar o init,
nemo sh são encontrados, o panic imprime a mensagem de erro na tela e
trava a máquina;
154
}
14 Linkado run_init_process(”/sbin/init”);
run_init_process(”/etc/init”);
Código compilado que foi run_init_process(”/bin/init”);

juntado as bibliotecas da run_init_process(”/bin/sh”);
linguagem e do sistema
operacional para se tornar
panic(”No init found. Try passing init= option to kernel. “
um executável pelo sistema
operacional. ”See Linux Documentation/init.txt for guindance.”)
Figura 77 - Trecho de init/main.c com tentativa de execução do init
h) ipc: este diretório contém o código de suporte à comunicação entre pro-

cesso (inter process communication). É bem interessante observar como um
processo troca mensagens com outro, por exemplo;
i) lib: contém o código de bibliotecas de funções usadas como elemento de
apoio em quase todos os módulos do kernel, para converter valores e im-
primir e ler dados por exemplo. Encontramos, também, funções básicas de
compressão;
j) Sound: contém o código-fonte do suporte a som no Linux, lembramos que
atualmente usamos o ALSA, mas ainda existe o suporte a opensound;
k) virt: contém o suporte à virtualização no kernel, item cada vez mais impor-
tante hoje em dia;
l) Security: contém o suporte a ajuste de segurança no kernel, o chamado har-
dening Linux;
m) Drivers: este diretório contém o código fonte de suporte aos dispositivos
que o Linux pode usar e está organizado por classe de serviço. Como exem-
plo, visite o diretório bluetooth e encontre lá o código de suporte a bluetooth
no kernel.
A organização do suporte a drivers de dispositivos está feita em diversos di-
retórios, respeitando se o dispositivo é de bloco ou de caractere.
Lembre-se que, além do suporte a drivers, em algum momento, você tam-
bém deverá prover o arquivo de firmware para o dispositivo funcionar;
n) Include,Samples, tools: consistem em ferramentas de apoio à compilação,
além dos Includes.
KERNEL
Como o nome diz, essa é a parte central do kernel do Linux, onde encontramos,
por exemplo, a parte de escalonamento.
155
Os diretórios presentes no kernel podem variar de versão em versão, mas não

estarão distantes do apresentado. Uma das razões é que essa visão de organiza-
ção já possui alguns anos (desde 1972 com o Unix o que é um tempo razoável).
COMPILAÇÃO FIXA, MODULAR
O código do kernel possui um conjunto muito grande de funções.

Você deve selecionar os itens que são essenciais para sua máquina no pro-
cesso de configuração. Isso parece uma tarefa trabalhosa, mas será apenas na
primeira vez, com o tempo verá que é um processo simples, bastando reconhecer
o hardware que dispõe.
As versões atuais do kernel permitem além da compilação fixa, em que marca-
mos um item que será compilado e linkado14 ao executável final, a compilação mo-
dular. Neste caso, a parte marcada como M (de Module) será compilada, mas num
arquivo binário diferente, que somente será carregado em memória se necessário.
Vamos a um exemplo.
Supondo que você possua diversos computadores com placas de rede dife-
rentes, você terá de compilar um kernel diferente para cada um? Não. Podemos
habilitar no kernel como módulo o suporte a todos os modelos de placa de rede
ethernet que possua na sua rede local. Ao ser bootado, no kernel será detectado o
módulo necessário e ele será carregado, em uma máquina específica, habilitando
o suporte à função. Os módulos depois de instalados ficam residentes em /lib/
modules/xxx, onde xxx é nossa versão de kernel, em nosso exemplo seria 2.3.9
depois de compilado e instalado.
A princípio quase todas as partes do kernel podem ser compiladas como mó-
dulos. Contudo, lembre-se que, se fizer isso para tudo, terá um processo de boot
mais lento.
Um cuidado é não compilar o suporte a sua controladora de HD ou ao seu
sistema de arquivo primário empregado (ext3, ext4 etc.) como um módulo por
precaução, pois podemos cair num erro de ter um kernel executável que depois
do boot inicial, não consegue enxergar o disco rígido ou a partição onde está o
resto do sistema operacional.
Neste tópico, aprendemos que o kernel possui diversos diretórios onde estão
o código-fonte de cada função-chave dele. Vimos que podemos compilar o kernel
de forma única ou segmentá-los com o suporte à modularização. Conhecemos a
organização do kernel e onde procurar a documentação, estando aptos a realizar
a tarefa de ajustes no kernel.
156
3.2.6 PARAMETRIZANDO ASPECTOS GERAIS, VERSÃO E .config

15 Parametrizar
Se desejamos compilar o kernel do sistema operacional Linux, antes de tudo
Selecionar as opções
desejadas. devemos parametrizá-lo15, focando nos recursos e requisitos de nossa empresa
ou indústria. Vamos começar essa tarefa e, para isso, contaremos com o auxílio de
uma série de programas para gerar nosso makefile (que automatizará a compila-
ção do kernel) de forma customizada e podermos compilar nosso código.
Neste tópico, veremos que essa atividade pode ser feita de diversas formas.
MODO TEXTUAL INTERATIVO
Neste caso, usaremos o comando make config, que executará um script que
para cada item do kernel. Perguntando ao usuário se deseja usar a função (Y), não
usar (N) e usar como módulo (M), é uma forma demorada e sujeita a erros, contudo
foi a única que existiu durante muito tempo. Temos um exemplo na figura a seguir.
Thiago Rocha (2012)
Figura 78 - Uso do make config
TEXTUAL BASEADA EM MENU
A personalização pode ser feita por meio de um sistema de configuração ba-

seado em menus, onde podemos habilitar e desabilitar todo um bloco. Também
temos acesso a um sistema de Help que pode sanar eventuais dúvidas em relação
ao item, o qual seria a sugestão do desenvolvedor, de habilitar ou desabilitá-lo. O
acesso a essa opção é feito digitando o comando:
make menuconfig.
Você terá após a compilação dos aplicativos de menus, acesso a algo parecido
com a figura seguinte, onde vemos no rodapé a opção de selecionar o item (en-
trar no submenu), sair ou Help.
157
O modo texto é a forma mais prática e produtiva de configurar as opções do

kernel, permitindo fácil acesso remoto e gastando poucos recursos.
Thiago Rocha (2012)

Figura 79 - Uso de make menuconfig
MODO GRÁFICO
Se você é daqueles usuários que não sobrevivem sem um mouse e uma inter-
face gráfica, esta opção vai lhe agradar. Empregando o comando make xconfig,
você terá uma interface gráfica em que poderá trabalhar com mouse e de forma
flexível, um exemplo está na figura a seguir.
Thiago Rocha (2012)
Figura 80 - Uso do make xconfig
Lembramos que independente da opção que empregarmos, seja textual ou

gráfica, o mais importante é saber o que fazer. Estaremos em nosso trabalho
usando o make menuconfig pela simplicidade de trabalho e produtividade.
158
Um ponto que devemos levar em conta é que o processo de compilação solici-

tará muito processamento e memória, e o kernel do Linux é razoavelmente exten-
so, logo se evitarmos o uso de interface gráfica durante esse processo termos um
ganho de recursos que pode ser usado pela compilação de forma sensível. Então,
se optar por usar o xconfig, após os ajustes procure ir para linha de comando. O
gerenciador de janela consome bastante memória.
.config
O kernel mantém as opções que você selecionou no arquivo .config em seu

diretório raiz, se o mesmo não existir será criado. Se, desejar instalar um kernel
totalmente novo, pode copiar seu arquivo de configuração antigo para o novo di-
retório. Vai economizar muito tempo por já ter suas preferências de configuração.
CONFIGURAÇÃO DE PARÂMETROS GERAIS
Antes de focarmos em pontos-chave do kernel, devemos ajustar parâmetros

que afetarão todos os módulos do Linux, no menu principal. Veja essa opção e
vamos entrar nela. No menu principal, ao selecionar a opção general setup, tere-
mos uma tela como a figura a seguir.
Thiago Rocha (2012)
Figura 81 - General setup kernel

159
Onde pode selecionar itens importantes para o kernel, em especial, temos:
Odirlei Batista
[*] Prompt for development and/or incomplete code/drivers
Figura 82 - Item selecionado em general setup kernel
Se habilitada essa opção, partes de softwares presentes no kernel serão apre-

sentados como opção para compilação junto dele. Muitas dessas partes (em es-
pecial drivers de dispositivos) podem estar em desenvolvimento ou mesmo in-
completos.
Nesse item, vale a pena uma discussão maior, visto a grande vantagem do Li-
nux em relação ao BSD Unix, por exemplo, é seu suporte a novos hardwares que
surgem dia a dia e com o suporte que prontamente é incorporado ao kernel. Se
desabilitarmos a opção, perdemos essa vantagem, contudo se deixarmos habilita-
da, podemos ter código incompleto ou ainda instável em nosso kernel compilado.
A melhor alternativa consiste em deixar habilitado e em cada módulo/driver,
analisar depois se vamos habilitar a característica em desenvolvimento ou não.
É essencial que uma parte seja habilitada. Pode parecer estranho lidarmos com
software que ainda está em desenvolvimento e tê-lo em produção. Um exemplo
disso acontece com um servidor. Mas muito software existente em alguns siste-
mas operacionais comerciais talvez seja menos estável e não tenha sido testado
tanto quanto o que você usará no Linux.
() Local version - append to kernel release

Odirlei Batista
[ ] Automatically append version information to the version

string
Figura 83 - Informação da versão do kernel
Essa característica permite gerar um nome de kernel customizado de forma

tal a não confundirmos qual versão estamos usando. A primeira linha permite
definirmos um nome para nosso kernel, a segunda se habilitada garante um se-
quencial para o kernel.
Odirlei Batista
< > Kernel .config support
Figura 84 - Gerar .config
Habilitar a característica de gerar um arquivo .config com nossas seleções de

opções para compilar o kernel é muito útil. Se observarmos nesse e em outros
itens, temos a opção de help. Experimente clicar em help e veja a mensagem in-
formativa que surgirá dizendo o que essa opção faz.
160
Temos muitas outras opções que você pode visitar e ler a documentação, mas
vamos voltar à tela anterior, selecionando exit na base da tela. Nessa tela, encon-
tramos algumas opções importantes.
Odirlei Batista
[*] Enable loadable module support
Figura 85 - Habilita o suporte a módulos no kernel
Essa opção habilita o suporte a módulos no kernel. Vamos habilitar e entrar

nela.
Você verá que o suporte a versões do kernel (module version support) é capaci-
dade de usar um módulo compilado em outra versão. Importante quando temos
apenas o binário do driver, por exemplo. Leia o help das demais opções e depois
volte ao menu principal selecionando exit.
Odirlei Batista
-*- Enable the block layer
Figura 86 - Suporte a Blocos
Diz ao kernel como tratar a questão de suporte a blocos e grandes arquivos

(maiores que 2 Terabytes), bem como qual escalonador de I/O usarmos.
Odirlei Batista
Bus options (PCI etc.)
Figura 87 - Tratamento do PCI
É uma opção muito importante, pois permite parametrizarmos como será re-
alizado o tratamento de barramentos de expansão. Podemos parametrizar como
o tratamento do pci será realizado, bem como o suporte a outros barramentos.
Lembre-se que nem todas as opções devem estar habilitadas, se sua máquina não
possui MCA ou ISA, por que habilitar essa opção? É removendo pequenas porções
de software não utilizados que conseguimos um kernel menor e por consequência
maior otimização de recursos.
Note itens-chave como PCI Access mode, o suporte a PCI express e o suporte a
PCCARD. Este último suporta os barramentos de expansão PCMCIA e CardBus nos
notebooks. Voltemos ao menu principal.
Odirlei Batista
Executable file formats / Emulations
Figura 88 - Informação sobre o formato dos arquivos

161
Permite dizer como será o formato dos arquivos que o kernel (sistema opera-
cional) poderá executar - o ELF e a.out.
O suporte à emulação também é provido aqui.
Você aprendeu, neste tópico, que existem diversas formas de realizar a para-
metrização do kernel. Vimos que existem muitas opções-chave, onde encontra-
mos no menu principal de configuração. Entendemos que a escolha de opções
tem efeito sobre todo o restante do processo de parametrização/compilação.
3.2.7 PARAMETRIZANDO PROCESSADOR E SMP
Imagine que sua máquina possui um processador, top de linha, com recursos
fantásticos, seja em quantidade de núcleos ou suportes à multimídia. Certamente
você gostaria que esses recursos fossem todos usados. Vamos aprender neste tó-
pico como habilitar o suporte a processadores específicos.
Os processadores atuais possuem, a cada dia, recursos de alto desempenho
em capacidade de processamento bruta, em indexação de memória ou suporte
a multimídia.
Cada novo processador que surge possui características que lhe são únicas no
desempenho, nas capacidades nativas ou no gerenciamento de energia.
Se desejarmos uma máquina para usar como servidor, certamente o I/O otimi-
zado é chave, temos como exemplo os AMD Opteron e Intel Xeon. Se pensarmos
em uma máquina portátil baseada em bateria, soluções que maximizem o de-
sempenho versus gasto de energia são o foco. Como exemplo, citamos o Atom, o
Neo e o Via c7.
O suporte a 16, 32 ou 64 bits é outra característica importante, que se suporta-
das devem ser habilitadas no kernel.
Em outro extremo, temos o sistema operacional que faz uso dessa arquitetura
da máquina e dos recursos do processador. A parametrização do sistema opera-
cional para suportar toda a potencialidade do processador é a chave.
O Linux pode ser compilado pensando em um hardware minimalista e antigo
como o Pentium clássico de 1985, mas é de se imaginar que vamos tirar o máximo
de proveito do nosso processador habilitando e usando as características únicas
e principais de cada um. Em especial o recurso de gerenciamento de energia, su-
porte a vários núcleos, linhas de execução (HT no P4) ou vários processadores por
cada máquina nós são principais.
No menu principal de configuração do kernel (usando make menuconfig),
você notará a opção:
162
Odirlei Batista
Processor type and features
Figura 89 - Terminal: make menuconfig
Nosso trabalho estará centrado nela. Entre na opção e lhe será mostrada uma
figura semelhante à seguinte (que apresenta apenas um corte parcial), onde ob-
servarmos campos-chave (principais) que logo descreveremos:
Thiago Rocha (2012)
Figura 90 - Tela de ajuste de processador no kernel 3.2.9 Odirlei Batista
[*] Symmetric multi-processing support
Figura 91 - Habilitando o suporte a multiprocessadores
Habilita o suporte a múltiplos processadores no kernel, permitindo o uso de

SMP para coordenação das ações entre os diversos processadores.
Odirlei Batista
Processor family (Pentium-Pro) --->
Figura 92 - Escolha do processador
Este submenu permite escolher o processador que você possui. Note que no
texto está escrito Pentium-Pro, que é a opção default do kernel 3.2.9. Se você tem
outro processador, deverá ajustar de um modo a obter o desempenho devido.
163
Os processadores são agrupados em famílias de processador. Tenha certeza

de qual processador possui para não compilar o kernel com recursos que não pos-
sua na máquina ou deixar de usá-los.
Por uma questão de compatibilidade com hardware antigo, muitas distribui-
ções ainda trazem o kernel compilado para o Intel 486.
Esse é um local onde o ajuste é feito de forma adequada e terá um desempe-
nho excelente.
Um fato interessante é ver que o primeiro processador suportado pelo Linux é
o Intel 386. Isso acontece por ser o primeiro processador da Intel que possuía um
mecanismo de gerenciamento de memória com segmentação, página e proteção
de memória. Os dois últimos requisitos são chaves para se ter um sistema opera-
cional multiusuário/multitarefa como o Linux.
Odirlei Batista
[*] Generic x86 support
Figura 93 - Processador suportado
Essa opção é uma visão oposta da anterior. No lugar de incorporar no kernel

compilado, otimizações presentes em apenas modelos específicos de processador
otimizam o kernel para a arquitetura x86 o que permite uma melhor portabilidade.
Odirlei Batista
(8) Maximum number of CPUs
Figura 94 - Quantidade de processadores
Anteriormente, temos a habilitação da quantidade de processadores que o

kernel pode lidar. Ajuste, de forma que corresponda ao que não tiver estruturas
muito grandes no kernel. No exemplo, temos oito CPUs.
Esta opção permite ilustrar a questão de ajustes condicionais. Desabilite a op-
ção de Symetric multiprocessing e verá que a opção de definir a quantidade de
CPUs some, além de uma série de outros itens que poderíamos setar. Como não
temos suporte a SMP, não faz sentido habilitar características correlatas a SMP, a
ferramenta de compilação nos ajuda nisso.
Lembramos que ter mais de um processador, dois, por exemplo, não significa
dobrar a capacidade, já que temos gastos associados à distribuição de carga entre
as diversas CPUs. O segundo ponto é que ter mais de uma CPU significa um au-
mento sensível de complexidade do gerenciador de processos.
Se desejar mais de oito CPUs habilitadas, a complexidade cresce, então você
deve marcar a opção
164
Odirlei Batista
[ ] Support for big SMP systems with more than 8 CPUs
Figura 95 - Opção para habilitar 8 CPUs
Odirlei Batista
High Memory Support (4GB) --->
Figura 96 - Quantidade máxima de memória física
Essa opção indica ao kernel a quantidade máxima de memória física que ele
pode endereçar.
No exemplo, temos 4 GB, se tivermos mais que isso de memória, ela não será
usada.
Lembre-se que a quantidade máxima de memória endereçável em uma máquina
depende da capacidade do processador. E dentro do sistema operacional, do tama-
nho do index. Um exemplo com 8 bits (1 byte) endereçamos 256 bytes, com 32 bits
endereçamos 4 GB, com 64 bits teríamos bem mais memória endereçável, mas o ta-
manho das tabelas cresce. O kernel atualmente suporta endereçar até 64 GB de RAM.
Odirlei Batista
[ ] Paravirtualized guest support --->
Figura 97 - Virtualização de hardware
Cada vez mais, cresce o uso de virtualização de hardware, com o aumento do

número de núcleos nos processadores. Uma abordagem eficaz é o uso do suporte
do hardware para virtualização e executar o nosso sistema operacional sobre um
hipervisor. Essa opção habilita a capacidade do kernel ser executado desta forma,
sobre diversos hipervisores.
Odirlei Batista
Preemption Model (Voluntary Kernel Preemption (Desktop)) --->
Figura 98 - Escalonador preemptive
Sistemas operacionais multitarefa exigem um escalonador preemptive, mas

existem diversas formas de ajustar o algoritmo. Temos uma das maiores vanta-
gens, o Linux, que com o mesmo código-fonte nos permite escolher se queremos
um escalonador focado em desktop (de baixa latência ou não) ou para um servidor.
Certifique-se que parametrizou essa opção, conforme seu ambiente de execução.
Além das características destacadas, existem outras que podem ser úteis, visi-
te-as e veja a documentação através do help.
165
APM E ACPI
APM e hoje ACPI são ferramentas muito úteis (<http://www.acpi.info/>).

A opção:
Odirlei Batista
Power management and ACPI options --->
Figura 99 - Gerenciamento de energia, suporte a hibernação, suporte a suspensão de execução
A figura anterior está relacionada a gerenciamento de energia, suporte à hi-

bernação, suporte à suspensão de execução (típicas de notebooks) e permite o
suporte a ajuste de velocidade do processador em equipamentos móveis quando
operando somente em bateria ou em baixa bateria. Observe e as diversas opções
serão bastante úteis a você.
Vamos relembrar! Cada processador possui características que lhe são únicas,
importantes e o sistema operacional deve ser parametrizado, no caso do kernel
linux, compilado para tirar vantagem do processador. Devemos nos certificar qual
processador possuímos e quais recursos podemos habilitar para não termos um
kernel que não funcione.
3.2.8 PARAMETRIZANDO Device Bloco pata/sata/scsi
Ao perguntar há alguns anos a alguém onde estavam seus dados, documen-

tos, vídeos ou fotos, a resposta seria na gaveta, nas fitas VHS e impresso em papel,
respectivamente. Hoje, se você pensar onde estão seus dados, certamente dirá
que estão num disco de armazenamento secundário, seja ele disco rígido tradi-
cional ou disco SSD (solid state disk).
Vamos compreender, neste tópico, onde esses itens estão suportados no ker-
nel para que você possa ajustá-los.
O armazenamento secundário consiste em um elemento-chave no nosso uso
do computador.
Relembrando que, como todos periféricos, os de armazenamento obedecem
à logística de ter uma controladora, um meio de comunicação e o dispositivo em
si. No caso de armazenamentos, as soluções mais empregadas atualmente são os
IDE, nas variantes PATA e SATA e o SCSI.
Devemos habilitar os diversos drivers de dispositivos para que nosso HD seja
reconhecido, assim como nosso CD-ROM, DVD e outros. É uma tarefa simples,
mas podem ocorrer erros.
166
O comando lspci pode ser nosso aliado novamente, por permitir listar as con-
troladoras de periféricos presentes no barramento de expansão.
A figura a seguir apresenta uma saída do comando lspci executado em uma
placa Abit de mercado.
Notamos o device IDE interface que foi marcado em vermelho. Se você desejar
detalhes, pode usar o lspci –v. Para obter mais opções do comando lspci, execute
o comando man lspci.
Podemos notar também diversos outros dispositivos na listagem.
root@aldeia:~# lspci
00:00.0 RAM memory: nVidia Corporation MCP55 Memory Controller
(rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev
a2)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
(rev a2)
00:02.0 USB Controller: nVidia Corporation MCP55 USB Controller
(rev a1)
(rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
00:05.0 RAID bus controller: nVidia Corporation MCP55 SATA
Controller (rev a2)
Controller (rev a2)
Controller (rev a2)
00:06.0 PCI bridge: nVidia Corporation MCP55 PCI bridge (rev
a2)
00:06.1 Audio device: nVidia Corporation MCP55 High Definition
Audio (rev a2)
00:08.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:09.0 Bridge: nVidia Corporation MCP55 Ethernet (rev a2)
00:0a.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge
(rev a2)
00:0c.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge
(rev a2)
00:0d.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge
(rev a2)
00:0e.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge
(rev a2)
00:0f.0 PCI bridge: nVidia Corporation MCP55 PCI Express bridge
(rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8
[Athlon64/Opteron] HyperTransport Technology Configuration
[Athlon64/Opteron] Address Map
[Athlon64/Opteron] DRAM Controller
[Athlon64/Opteron] Miscellaneous Control
Thiago Rocha (2012)
01:08.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A

IEEE-1394a-2000 Controller (PHY/Link)
06:00.0 VGA compatible controller: nVidia Corporation NV44
[GeForce 7100 GS] (rev a1)
Figura 100 - Listagem de dispositivos via lspci

167
Vamos observar a listagem, pois seu uso pode ser útil no futuro.
Além da controladora de HD que procuramos, estão todos os outros
dispositivos.
Foi marcada em vermelho também a parte de RAID em que podemos ligar
um HD.
Conhecendo o hardware, vamos entrar no menu principal em Device drivers e
depois em uma das opções a seguir.
Odirlei Batista
< > ATA/ATAPI/MFM/RLL support (DEPRECATED) --->
SCSI device support --->
<*> Serial ATA and Parallel ATA drivers --->
Figura 101 - Opções após Device drivers
A primeira opção está desatualizada. Consiste no antigo suporte a disco do

tipo PATA IDE e discos não padronizados para PC (MFM e RLL). Hoje o suporte
a PATA IDE foi levado para a terceira opção. Essa opção é mantida apenas por
compatibilidade.
Na segunda opção, encontraremos o suporte a discos e dispositivos que em-
preguem SCSI e, finalmente, a última, o suporte a SATA e PATA.
Visite as opções e note que, além dos drivers de dispositivos para controla-
doras como a Nvidia, você encontrará parâmetros de ajuste tanto no SCSI como
SATA/PATA.
Encontramos a opção a seguir que permite lidar como o suporte a volumes
lógicos (LVM) e a RAID, que são elementos importantes para o requisito de dispo-
nibilidade em segurança e a questão de flexibilidade na administração de discos.
Em relação à identificação, os HDs do tipo PATA serão identificados como dis-
positivo hda, hdb, hdc e assim por diante, os SATA e SCSI como das, sdb, sdc,
em diante.
Unidades de fitas também são habilitadas nessas opções, no caso responde
tipicamente como st0, st1,… As unidades de CD scsi possuem uma denominação
especial: sc0, sc1 etc.
Odirlei Batista
[*] Multiple devices driver support (RAID and LVM) --->
Figura 102 - Suporte a volumes lógicos
Habilite a mesma, veja em seu submenu as opções disponíveis para implanta-

ção de LVM e RAID.
168
Em sua instalação, certifique-se de habilitar o suporte ao drivers de dispositivo

adequado. Fique atento, pois pode existir mais de um driver para o dispositivo e
cabe a você escolher qual.
Existem casos em que a comunidade de software livre escreve um driver e de-
pois o fabricante do hardware faz o mesmo, ficando então duas implementações.
Você entendeu, neste tópico, que o suporte a disco é um elemento-chave.
Aprendeu como habilitar os módulos corretos no kernel, levando em conta o tipo
de controladora, se é SCSI, SATA ou PATA e também utilizou do comando lspci
como exercício.
3.2.9 PARAMETRIZANDO DEVICE DE REDE
Você já pensou se a internet não existisse? Provavelmente, sem ela seu com-
putador teria pouca utilidade. O suporte à rede é um elemento importante em
um sistema operacional. Vamos aprender, neste tópico, como ajustar o suporte
no Linux.
Atualmente, um computador, notebook, tablet ou um celular que não esteja
conectado à rede internet é difícil de imaginar e teria pouca utilidade. Sabemos
que existem diversas opções de conectividade à rede internet, sendo as princi-
pais: rede cabeada, via ethernet, rede sem fio (WiFi, bluetooth), rede discada via
modem e acesso via rede UTMS celular (3G).
Além das tecnologias de rede em nível de camada de enlace citadas, temos
ainda elementos-chave a serem considerados:
a) interface de rede: é a chave para a conectividade a uma determinada tec-
nologia de enlace e física. A interface de rede apresenta-se como uma placa
de expansão PCI/PCI-E onboard ou não, uma placa USB (Universal Serial Bus)
ou PCMCIA (Personal Computer Memory Card International Association), den-
tre outros formatos. A placa de rede necessita de um driver de dispositivo
para funcionar no sistema operacional;
b) suporte a TCP/IP: sejam IPV4 ou IPV6 e todos os protocolos relacionados
a ele. Por uma questão de desempenho ao longo do tempo, o TCP/IP foi
implementado no kernel do sistema operacional. A primeira implementação
de TCP/IP realizada foi feita em ambiente Unix e passa pelos demais sistemas
operacionais. Se desejarmos ter TCP/IP, devemos habilitá-lo e configurá-lo;
c) suporte a firewall com filtragem de pacotes: cada vez mais é necessário se
filtrar conteúdos da internet, a implementação de filtros de pacotes em nível
de kernel junto ao TCP/IP tem sido a prática.
169
Vamos aprender sobre o suporte de rede do ponto de vista de protocolos, tec-

nologia apresentada, de interface (controlador de dispositivo) com a habilitação
de seu driver.
O SUPORTE À INTERFACE
O suporte a drivers de dispositivos está localizado no item Device drivers, no

menu principal.
Ao entrar nele, encontraremos o item [*] Network device support. Se não de-
sejar suporte à rede no computador, basta desmarcar esse item. Vamos visitá-lo.
Ao entrar, terá uma tela como a seguinte:
--- Network device support

-*- Network core driver support
< > Bonding driver support
.... < trecho recortado >
Odirlei Batista
[ ] Wan interfaces support --->
< > VMware VMXNET3 ethernet driver
Figura 103 - Device drivers
Onde recortamos um trecho, sendo os principais itens:

Odirlei Batista
[*] Ethernet driver support --->
Figura 104 - Trecho recortado
O suporte às placas ethernet de diversos fornecedores e velocidades, entre no

item e procure pela placa de rede que possui instalada, você notará que a lista de
placas suportadas é bem extensa.
Odirlei Batista
< > Universal TUN/TAP device driver support
Figura 105 - Configuração de interfaces virtuais
Essa opção nos permite configurar interfaces virtuais que serão usadas na
construção de VPN (Virtual Private Network – Rede privada Virtual).
Odirlei Batista
< > PPP (point-to-point protocol) support
Figura 106 - Habilitar protocolo PPP

170
Habilita o protocolo PPP que permite ligação ponto a ponto. É muito usado
para acesso à banda larga e juntamente com TUN/TAP para construir VPNs (Virtu-
al Private Network- Rede privada Virtual).
Odirlei Batista
USB Network Adapters --->
Figura 107 - Suporte à rede via USB
Possui o suporte à rede via adaptador USB. Se estiver usando um adaptador

desse tipo, procure dentro do item se ele está lá e habilite-o.
Odirlei Batista
[*] Wireless LAN --->
Figura 108 - Suporte a rede sem fio
Habilita o suporte à rede sem fio via IEEE 802.11 em termos de controladoras.
Existem muitos outros itens no submenu, mas você pode se aventurar neles
posteriormente.
Vamos voltar ao suporte a protocolos e elementos que fazem uso das interfaces.
O SUPORTE A REDES E PROTOCOLOS
Voltando ao menu principal, vá ao item:
Odirlei Batista
[*] Networking support --->
Figura 109 - Suporte à rede
Você encontrará o suporte à rede propriamente dito, incluindo os diversos

protocolos empregados.
Lembre-se que as opções são várias, até porque o TCP/IP não é o único conjun-
to de protocolos usados no mercado, é só o mais comum. Vejamos então:
Odirlei Batista
-*- Wireless --->
Figura 110 - Suporte a Ieee802.11
Contém o suporte a Ieee802.11, independentemente da interface, ou seja, do

protocolo.
171
Odirlei Batista
< > Bluetooth subsystem support --->
Figura 111 - Suporte a bluetooth
Temos o suporte a bluetooth muito usado em PANs, em especial com o cresci-

mento de integração de celulares e tablets. No submenu, poderemos ajustar o que
desejarmos e a lista dos dispositivos suportada também está lá, dê uma olhada.
NETWORKING OPTIONS
Este submenu contém os elementos-chave de configuração da rede. Fique

atento para não desmarcar algum item chave, pois pode ter a rede funcionando
de forma incompleta.
Odirlei Batista
[*] TCP/IP networking
Figura 112 - Configuração de rede: opções
Possui uma lista muito grande de itens e simplesmente habilita o suporte a

TCP/IP. Em especial, temos:
a) IP multicasting e IP multicast routing: habilitam a capacidade do Linux,
atuam em uma rede do tipo multicast (classe D) suportando PIM-SM 1 e 2;
b) IP kernel level autoconfiguration: ao habilitar essa característica, permiti-
mos ao kernel suportar os protocolos DHCP, Bootp e RARP, que são essen-
ciais juntos com um servidor PXE, para termos máquinas diskless (sem disco);
c) The IPv6 protocol: habilita o suporte a protocolo IP Versão 6 no kernel, im-
portante neste momento, pois a internet está migrando para o IPV6;
d) Network packet filtering framework (Netfilter): habilita o suporte a filtro
de pacotes.
Diversas outras opções estão disponíveis, algumas interessantes e importan-
tes com o suporte Ipsec e IEEE802.1d e IEEE802.1Q e outras experimentais.
Pesquise, você pode gastar um bom tempo compreendendo melhor como
configurar e mais detalhes sobre redes também. Não deixe de visualizar os arqui-
vos-fontes, alguns lhe serão muito interessantes. Já pensou como é o código do
protocolo IP? Ele está disponível para melhor entendê-lo.
Aprendemos que o suporte a redes, atualmente, é um elemento essencial e
o Linux faz isso muito bem, permitindo uma forte personalização dos itens que
compõem a rede, tanto em nível de interface como de protocolos e serviços.
172
3.2.10 PARAMETRIZANDO FILTRAGEM DE PACOTES/NETFILTER

16 Advanced netfilter
configuration Existem diversas abordagens para se realizar o controle de acesso de borda
Configuração avançada do à internet, sendo os mais comuns o filtro de pacotes e proxy. Vamos descrever,
netfilter, permite ajustes neste tópico, a implementação de filtro de pacote do kernel, bastante usada no
finos no netfilter.
mercado.
O suporte a filtro de pacotes no kernel do Linux e do BSD Unix constitui ele-
17 IP virtual server mentos-chave do seu sucesso. Para ser usado em máquinas, desempenha o papel
support de firewall, tanto em um computador comum quanto em appliance dedicado.
Suporte a servidor virtual O módulo iptables, ou netfilter, é o suporte à filtragem de pacotes que integra
IP, permite configurar um
cluster de máquinas em o kernel 2.4 em diante, sendo usando atualmente na versão 3. Ele se encontra
kernel.
integrado à configuração do TCP/IP tanto no IPV4 como no IPV6. Para usá-lo, as
características de filtragem de pacote devem ser habilitadas.
Podemos ter acesso à sua configuração entrando em Networking support no
menu principal e depois Networking options, onde encontra o menu.
Odirlei Batista
[*] Network packet filtering framework (Netfilter) --->
Figura 113 - Acesso ao filtro de pacotes
Vamos entrar nesta opção e visualizar o que fazer. O seguinte menu será apre-
sentado:
--- Network packet filtering framework (Netfilter)

[ ] Network packet filtering debugging
[ ] Advanced netfilter configuration
Core Netfilter Configuration ---> < > Odirlei Batista (2012)
IP set support ---> < > IP

virtual server support ---> IP:
Netfilter Configuration ---> IPv6:
Netfilter Configuration --->
Figura 114 - Menu encontrado
A segunda opção, Advanced netfilter configuration16, é importante estar

marcada para que todos os módulos do netfilter sejam mostrados para escolha.
Atenção à separação de filtragem no IPV4 e no IPV6.
A opção IP virtual server support17(IPVS) não é um elemento de filtragem em
si para segurança, mas para implementar segurança do ponto de vista de dispo-
nibilidade, criando um servidor Linux virtual espalhado pela rede, em um arranjo
de duas ou mais máquinas.
Um elemento interessante no apoio à filtragem de pacotes consiste no pa-
cote l7-filter, disponível em <http://l7-filter.sourceforge.net/>, que permite im-
173
plementar filtragem a nível de aplicação. Atualmente é um patch apenas para o

kernel 2.4 e 2.6, não estando plenamente testado no kernel 3.0. Esse é um exemplo
do fato que nos leva a usarmos uma versão antiga de kernel.
Para testarmos e conhecermos mais o l7-filter e netfilter, use a distribuição ze-
roshell. Acesse o site e faça o seu download em <htttp://www.zeroshell.org>.
Percebemos que segurança é um elemento essencial no nosso dia a dia.
Aprendemos, neste tópico, que o Linux facilita a implementação de segurança
em nível de perímetro de rede e de disponibilidade.
3.2.11 PARAMETRIZANDO DEVICE DRIVERS
Você já pensou que toda porta tem uma fechadura que pode ser igual, mas a
chave é diferente?
Em cada lugar que os recursos forem usados, as características podem mudar.
Em computação da mesma forma, os dispositivos periféricos podem mudar suas
características básicas de IRQ, I/O e DMA dependendo de onde estiverem.
Todo hardware periférico suportado pelo sistema operacional deve ter um De-
vice driver associado a ele e o driver deve estar funcional.
Para colocar um dispositivo no computador, precisamos da controladora,
meio de comunicação e dispositivo. A controladora como elemento de expansão
de nossa máquina necessita ser inserida em um barramento de expansão (hoje
tipicamente PCI e PCI-E) e ter seus endereços de I/O, IRQ, se for o caso DMA ajus-
tados, levando em conta o que já existe instalado na máquina.
Atualmente, com o emprego de barramentos de expansão PCI e com o uso de
USB, esse processo é feito de forma quase automática pela BIOS, a partir do con-
ceito de PnP, e negociado de forma a evitar conflitos e garantir a funcionalidade
devida do hardware. Contudo, existem situações que temos de ajustar os parâ-
metros básicos dos periféricos. No entanto, nos primeiros computadores, com o
barramento ISA, era feito de forma manual. Também pode ser feito tanto para
ISA como outros barramentos. Tente acessar sua BIOS e encontrará o local para
parametrizar o periférico.
Um exemplo clássico de conflito que existia era o uso de uma placa de expan-
são ISA que não permite negociação de configuração e tem seu dados básicos
setados via jumpers, seja IRQ, endereçamento de I/O, portas. Outra situação é que
precisamos ajustar por alguma razão de desempenho ou compatibilidade com
um software que estamos usando esses dados.
No ambiente Windows, o ajuste pode ser realizado no painel de controle com
relativa facilidade.
174
Clique em gerenciador de dispositivo e, na lista de dispositivos, em dispositivo

selecione propriedades e poderá parametrizar o Device driver. A figura a seguir
mostra um exemplo de placa de rede.
Thiago Rocha (2012)

Figura 115 - Gerenciador de dispositivos
No Linux, teremos de ajustar esses parâmetros manualmente, no código do

Device driver no kernel ou no arquivo de carga de módulos o rc.modules, por
exemplo. Essa atividade garantirá a compilação adequada do driver e sua conse-
quente funcionalidade, sua carga correta.
Na figura seguinte, temos um trecho de código do rc.modules, onde observa-
mos como deveria ser parametrizados alguns dispositivos. O comando pode ser
executado dentro do rc.module ou na linha de comando.
#/sbin/modprobe aztcd aztcd=<I/O address>

#/sbin/modprobe cdu31a cdu31a_port=<I/O address>
cdu31a_irq=<interrupt>
#/sbin/modprobe cm206 cm206=<I/O address>,<IRQ>
# Below, this last number is "1" for SoundBlaster Pro card, or
"0" for a clone.
#/sbin/modprobe sbpcd sbpcd=<I/O address>,1
#/sbin/modprobe sjcd sjcd=<I/O address>
#/sbin/modprobe sonycd535 sonycd535=<I/O address>
# CD-ROM drives on ISP16, MAD16 or Mozart sound card:
#/sbin/modprobe isp16 isp16_cdrom_base=<port>
isp16_cdrom_irq=<irq> isp16_cdrom_dma=<dma>
isp16_cdrom_type=<drive_type>
# where the values are one of: port=0x340,0x320,0x330,0x360
# irq=0,3,5,7,9,10,11
Odirlei Batista
# dma=0,3,5,6,7
# drive_type=noisp16,Sanyo,
Panasonic,Sony,Mitsumi
Figura 116 - Trecho rc.modules

175
Note que se você setar dois dispositivos com parâmetros iguais pode haver
um conflito de IRQ ou de I/O e nenhum dos dois funcionarem de forma correta
ou, pior, funcionarem de forma intermitente.
Entendemos que, por mais que seja fácil lidar com dispositivos, em alguns mo-
mentos teremos de fazer ajustes de baixo nível, dizendo ao sistema operacional
das características do hardware.
3.2.12 PARAMETRIZANDO SEGURANÇA
O Linux começou como um projeto sem grandes pretensões, mas hoje ocupa
um papel principal na indústria da tecnologia da informação. Se avaliarmos, mais
importante do que termos algo funcionando, em informática, é ter algo seguro.
Como projeto baseado no Unix, o Linux implementa ideias importantes de
controle de acesso aos seus recursos e tem facilidades de log e auditoria.
Ao longo do tempo, novas demandas têm surgido, visando um sistema ope-
racional mais seguro para ser usado em rede. O ato de tentar fechar e eliminar
falhas de seguranças, em especial as conceituais, é chamado de hardening.
Uma segunda questão importante tem sido suportar cada vez mais criptogra-
fia em computação e novos usos tem surgido, como exemplo a manutenção dos
dados em disco rígidos criptografados.
Vejamos, então, como habilitar todas as funcionalidades que estão presentes
no kernel do Linux. Antes de tudo, devemos estar atentos à opção (entre em Ge-
neral Setup no menu principal),
Odirlei Batista
[*] Auditing support

[*] Enable system-call auditing support
Figura 117 - Habilitar log de acesso ao I/O
A opção permite habilitar log de acesso ao I/O e chamadas ao sistema que po-
dem ser muito úteis na política de segurança e auditoria de sistemas.
No menu principal, encontraremos a opção Security options, que permite
configurar comportamentos seguros do kernel Linux. Examine a documentação
de cada uma das opções, clicando em help. Você notará itens que podem ser bas-
tante úteis.
Aprender mais sobre ajustar a segurança no kernel (hardening linux), pois é
muito importante. Visite o site do SELinux , <http://selinuxproject.org/>, lá exis-
tem muitas informações sobre essa segurança.
176
Outro elemento presente no menu principal é a opção é Kernel hacking, isso

18 Partição não tem nada a ver com hackear no sentido de ataque ao kernel, mas de realizar
Divisão lógica do disco
ajustes e otimizações de baixo nível no seu comportamento. Sugerimos que se-
rígido. jam feitos ajustes nas opções presentes de forma cuidadosa e quando tiver muita
certeza. Caso contrário, levará o sistema poderá ficar instável.
SUPORTE À CRIPTOGRAFIA
Criptografia consiste na cifragem de informações com o objetivo de garantir o

requisito de segurança de confidencialidade da informação e em algum momen-
to de integridade.
No menu principal do kernel, você encontrará a opção Cryptographic API,
onde estão descritos os algoritmos suportados no kernel para criptografia.
Você poderá realizar ajustes, habilitando e desabilitando funções do kernel no
suporte a criptografia. Essas funções implementadas em modo kernel são muito
importantes para dar maior velocidade às atividades, como a cifragem de uma
partição18 de disco, visto o gerente de arquivos e o módulo estarem em modo ker-
nel, ou no suporte a tarefas presentes no kernel, como a implementação de IPsec,
VNPs, cifragem em redes sem fio. Encontramos também o suporte a CRC usado
nas camadas de enlace ethernet no IP.
Concluímos que segurança é um elemento importante e podemos ajustar o ker-
nel para fazê-lo mais seguro e suportando criptografia como elemento de apoio.
3.2.13 PARAMETRIZANDO SISTEMAS DE ARQUIVOS
Você sabe como escrever a palavra cachorro em inglês e em espanhol? Em

português, escrevemos cachorro, em inglês dog, em espanhol pero.
Uma pergunta: chamar o cachorro de pero muda o fato de ele ser um cachor-
ro? Não. Existe uma distinção ao objeto físico, o cachorro, e como cada língua o
denomina, uma abstração virtual. Assim são nossos sistemas computacionais na
questão sistema de arquivo. Fisicamente, um arquivo é armazenado em disco ou
outra mídia e o Windows pode ver esse conjunto de bloco de uma forma e o Linux
de outra. Hoje trabalhamos com a ideia de que podemos ver os blocos de diversas
formas, respeitando os preceitos de nomes, atributos e organização do sistema
operacional. Existem muitos sistemas de arquivos, vamos descrever, neste tópico,
como habilitá-los no Linux e escolher um.
Um primeiro ponto sobre sistema de arquivos é que, quando realizamos a ins-
talação de seu sistema operacional após realizar o particionamento do disco, tive-
177
mos de escolher um sistema de arquivo para a partição, para depois formatar ela
(isso quer dizer organizar os blocos físicos e criar as estruturas básicas do sistema
de arquivo na partição). No ambiente Microsoft Windows, os sistemas de arquivos
comuns são o FAT e FAT32 vindos dos MS DOS e o NTFS (New Technology File Sys-
tem), o Linux emprega os sistemas de arquivos ext, ext2, ext3 e ext4. Além destes,
existem diversos que são suportados e podem ser usados.
Um fator impactante independentemente do tipo de sistema de arquivos é
a quantidade de blocos de disco (setores do disco), o sistema operacional alo-
cado por vez. Se muito pequeno, será ineficiente, se muito grande pode existir
fragmentação.
SELECIONANDO SISTEMAS DE ARQUIVOS NO KERNEL
No menu principal, você encontrará a opção File systems. Vamos entrar nela,
pois é lá que está o suporte a sistemas de arquivos. Destacaremos os elementos-
-chave presentes. A regra básica é: se você deseja lidar com uma partição com o
tipo de sistema de arquivo ou criar uma e usar deve habilitar a característica.
Odirlei Batista
< > Second extended fs support
Figura 118 - Habilitando característica
O chamado ext2 foi a opção primária usado no Linux até o kernel 2.4. Atual-
mente está sendo deixada de lado visto a existência de soluções melhores.
<*> Ext3 journalling file system support

.... [ ] Default to 'data=ordered' in ext3
.... [*] Ext3 extended attributes
Odirlei Batista
.... [*] Ext3 POSIX Access Control Lists

.... [*] Ext3 Security Labels
< > The Extended 4 (ext4) filesystem
Figura 119 - Suporte ao ext3
Aqui temos o suporte ao ext3 usado em grande parte das distribuições Linux
no mercado, bem como ao ext4 seu sucessor. No ext3 que está habilitado, pode-
mos notar opções, em especial, o suporte a ACL (Ext3 POSIX Access Control Lists),
recurso importante para implementação de segurança hoje em dia.
Odirlei Batista
< > JFS filesystem support
Figura 120 - Suporte a JFS

178
Apresenta o suporte a JFS (Journaled filesystem) doado pela IBM. Consiste em

uma excelente solução de sistema de arquivo, talvez das melhores no mercado.
Odirlei Batista
DOS/FAT/NT Filesystems --->
Figura 121 - Suporte a sistema de arquivos da Microsoft.
Aqui temos o suporte a sistema de arquivos da Microsoft. Utilizaremos muito

essa opção. Se tiver uma máquina com dual boot ou fizer uso de pen drivers, por
exemplo, ou sd, que usam fat/fat32.
Uma característica importante que notará dentro do menu é a de setar supor-
te à escrita em partições do tipo NTFS (NTFS write support).
Odirlei Batista
CD-ROM/DVD Filesystems --->
Figura 122 - Suporte a sistemas de arquivos para mídia ótica
Implementa o suporte a sistemas de arquivos para mídias óticas mais co-

muns, ISO9660 e UDF. Se quisermos usar um CD ou DVD, vamos precisar habilitar
essa opção.
Odirlei Batista
<*> Quota format vfsv0 and vfsv1 support
Figura 123 - Suporte a cota de uso de disco por usuário
Implementa suporte à cota de uso de disco por usuário, permitindo estabele-

cer um limite máximo por usuário de espaço usado.
Odirlei Batista
Pseudo filesystems
Figura 124 - Habilita pseudossistemas de arquivo
O Linux implementa monitoramente (e a possibilidade de alteração) as suas

estruturas de dados internas no sistema de arquivo. Vamos testar digitando cat /
proc/cpuinfo e teremos os dados do processador. Podemos habilitar esses pseu-
dossistemas de arquivo que mapeiam as estruturas em disco.
Odirlei Batista
[*] Network File Systems --->
Figura 125 - Habilita suporte de sistema de arquivo em rede

179
Habilita o suporte de sistema de arquivo em rede, tanto o suporte a NFS usado

no Unix/Linux como a CIFS da Microsoft e outras soluções de mercado.
O suporte a NFS é feita tanto em nível de cliente quanto servidor, incluído a
versão 4 do protocolo. Em máquina sem disco, podemos marcar a opção de boot
via nfs.
Encontramos nesta o suporte ao protocolo NCP dos antigos servidores novell
netware.
Thiago Rocha
-*- Native language support --->
Figura 126 - Suporte ao conjunto regional
Resolve o problema de ter conjuntos de caracteres diferentes regionalmente

e termos nomes de arquivos com caracteres que não americanos. O suporte ao
conjunto regional e ao UTF-8 é uma boa opção.
Em relação ao tamanho máximo de arquivo que o sistema pode suportar, essa
é uma opção que você poderá encontrar em enable block layer, no menu princi-
pal, tendo, é claro, as limitações de tamanho de cada tipo de sistema de arquivo.
Aprendemos que sistemas de arquivos são importantes e que existem vários
que podem ser configurados e suportados no Linux.
3.2.14 COMPILAÇÃO E INSTALAÇÃO DO NOVO KERNEL
Quando queremos realizar uma tarefa e entendemos todos os passos envolvi-

dos, realizando o devido planejamento, fica bem mais fácil e temos confiança que
dará certo. Em nossa jornada para ajustar o kernel Linux, chegamos ao momento
de compilar e instalar o kernel. Veremos como fazer essa compilação.
COMPILANDO
Após as devidas alterações na configuração do código-fonte do kernel via apli-

cativo (de sua preferência, seja o menuconfig ou xconfig), devemos proceder
com a compilação do kernel e sua instalação. Como verá, essa é a parte mais fácil
e talvez a mais demorada, já que é muito código para ser compilado.
O processo de compilação é desencadeado pelo comando:
180
Odirlei Batista
19 Executável
Make
Software ou aplicação que
pode ser executada pelo Figura 127 - Comando que desencadeia o processo de compilação
Esse comando aplicará as alterações, que realizamos na configuração, nos vá-

rios subdiretórios gerando os makefiles (arquivos de regras de compilação) para
cada porção do código e posteriormente o compilar.
Esse processo é relativamente demorado e o tempo de execução depende-
rá da capacidade instalada em termos de processador do computador, memória
principal e velocidade dos discos rígidos empregados.
Estamos falando em compilar não um aplicativo de alguns kbytes de tamanho,
mas o fonte de um sistema operacional que possui milhões de linhas de código.
No processo de compilação, todo o código necessário será compilado gerando
um arquivo imagem do Linux chamado vmlinux, o que compilamos será apenas
o sistema base, se habilitamos qualquer software/parte do kernel como módulo,
devemos proceder a compilação deles com o comando:
Odirlei Batista
make modules
Figura 128 - Comando para compilação dos módulos.
Esse comando realizará a compilação do módulos.

Nem sempre obteremos sucesso na compilação. Por mais que o kernel seja
atual em suas ferramentas de checagem de dependências, evite, por exemplo,
habilitar o suporte a firewall iptables sem habilitar o suporte à rede e TCP/IP. Pode-
mos também passar mais uma checagem e termos um erro de compilação. Pode-
mos selecionar uma arquitetura diferente da que temos suporte, ou tantos outros
erros, o que é importante que, se o executável19 do kernel e módulos não forem
compilados de forma adequada, devemos repetir o processo antes de proceder a
instalação de forma a não se colocar um sistema instável para executar.
REALIZANDO BACKUP DO KERNEL ANTIGO
Após esses dois passos, podemos finalmente instalar nosso novo kernel.
Mas antes é interessante que realizemos um backup do kernel que estamos
usando, para qualquer eventualidade de falha. Assim, teremos como continuar
usando a máquina. Isso pode ser feito de forma simples. Entre no diretório /boot
e liste os arquivos, a saída será algo como:
181
root@slvm:/boot# ls
README.initrd@ System.map-huge-smp-2.6.33.4-smp config-generic-
smp-2.6.33.4-smp slack.bmp vmlinuz-huge-smp-2.6.33.4-smp
System.map@ boot.0800 config-huge-
2.6.33.4 vmlinuz@
System.map-generic-2.6.33.4 boot_message.txt config-huge-smp-
2.6.33.4-smp vmlinuz-generic-2.6.33.4
System.map-generic-smp-2.6.33.4-
smp config@ diag1.img vmlinuz-generic-smp-2.6.33.4-
smp
System.map-huge-2.6.33.4 config-generic-
2.6.33.4 map vmlinuz-huge-2.6.33.4

root@slvm:/boot# ls -l vmlinuz
lrwxrwxrwx 1 root root 29 2011-04-07 18:47 vmlinuz ->
vmlinuz-huge-smp-2.6.33.4-
smp
Figura 129 - Diretório /boot, lista de arquivos
Você pode notar diversos arquivos, em especial o vmlinuz, que é um link sim-
bólico para o arquivo vmlinuz-huge-smp-2.6.33.4-smp, como pode ser visto pelo
ls -l logo a seguir (em vermelho).
Devemos realizar um cópia do arquivo vmlinuz em uso para vmlinuz.backup,
por exemplo, empregue o comando: Odirlei Batista
cp vmlinuz vmlinuz.backup
Figura 130 - Comando para backup vmlinuz
Agora no seu bootloader, seja lilo (<http://lilo.alioth.debian.org/>) ou grub

(<http://www.gnu.org/software/grub/>), gere uma nova entrada para o kernel
backup. Se tiver alguma dúvida sobre o boot loader utilizado, visite seus sites e
veja como lidar, criar e apagar entradas de boot neles.
Agora que temos um ponto de restauração do kernel para bootar por ele, se
nosso kernel compilado não funcionar podemos prosseguir.
INSTALANDO O NOVO KERNEL
Para realizar a instalação, você deve empregar o comando:

Odirlei Batista
make install
Figura 131 - Comando para instalação do novo kernel

182
Esse comando realizará a compressão do kernel (o arquivo gerado pela compi-

20 Bootável lação é o vmlinux), gerando o vmlinuz, copiando, a seguir esse executável para o
Mídia de armazenamento
/boot, onde residem as imagens bootáveis20 de sistema operacional.
secundário que contém
uma cópia do sistema Após a instalação do kernel em si, devemos instalar o módulos que compila-
operacional que pode ser mos, com o comando:
carregada na inicialização.
Odirlei Batista
make modules_install
21 Setarmos
Figura 132 - Comando para a instalação dos módulos compilados
Mudarmos ou ajustarmos.
Esse comando realiza a cópia dos módulos compilados para o diretório /lib/
modules/xxx, onde xxx é o nome da versão do sistema. Por exemplo, se instala-
mos o kernel 3.2.9, o diretório será /lib/modules/3.2.9 .
Fique atento, já que, se não setarmos21 o nome de nossa instalação nas opções
gerais do kernel e já estivermos usando a versão 3.2.9 e compilarmos os fontes da
mesma versão, os módulos que estavam no diretório serão subescritos. Se pre-
tendemos ter um ponto de restauração, faça backup dos diretórios de módulos
ou set um nome de versão para seu novo kernel diferente.
TESTANDO
Agora, você pode salvar qualquer arquivo aberto e rebootar a máquina. Se

tudo correr bem ao fazer o login e usar o comando uname –a, poderá visualizar a
versão do kernel que acabou de compilar. Existindo algum problema no processo
de boot sempre podemos bootar pela cópia do kernel que realizou e tentar com-
pilar seu novo kernel novamente.
Mostramos neste tópico que o kernel do Linux pode ser compilado e seus mó-
dulos também. Para evitar problemas com um kernel não funcional, devemos rea-
lizar o backup do kernel antigo gerando uma nova entrada no boot loader, seja lilo
ou grub. Aprendemos, também, que os processos de instalação do novo kernel.
3.2.15 RECUPERANDO-SE DE UMA FALHA
Tudo funciona desde que não dê errado. Contudo, para algo funcionar, de-
vemos ter procedimentos claros do que e como fazer, além de todas as partes
envolvidas no processo concordarem.
Ao compilar um novo kernel, existe uma gama razoável de problemas que po-
dem acontecer. Em especial, podemos:
183
a) não nos lembrarmos de assinalar algum item-chave importante. Por exem-

plo, digamos que usamos um sistema de arquivos ext4 e, ao compilar o
kernel, nos esquecemos de assinalar essa opção. O sistema operacional não
conseguirá acessar a partição de disco onde está instalado o restante do sis-
tema operacional, o kernel será executado, mas travará no init. O mesmo vale
para se esquecer de marcar o suporte a uma determinada controladora de
periférico, ou seja, este não funcionará. Imagine se for a controladora de dis-
co, não existirá suporte a disco e o sistema não terminará o boot. Se for de
outro periférico e ele não funcionar, isso é comum com a placa de rede;
b) perceber que deu erro em um ou mais pontos na compilação: seja no ker-
nel em si ou nos módulos, e termos mandado instalar, ainda assim teremos
instabilidade;
c) ver que no novo kernel foi retirado o suporte a uma função-chave que usa-
mos: seja funcionalidade ou suporte a hardware, ou a forma de configurar
esses recursos tenha mudado;
d) termos nos esquecido de habilitar uma funcionalidade. Exemplo, habilitar a
parte de rede, mas esquecer de habilitar o suporte a netfilter e ter o firewall
não funcionando;
e) não termos instalado o kernel de forma adequada. Se conseguiu instalar o
kernel, mas não o boot loader ou o fato de termos esquecido de instalar os
módulos com o make modules_install.
Em todos os casos, devemos voltar para a versão anterior de forma que pos-
samos trabalhar na máquina. Não é necessário reinstalar o sistema operacional.
Se foram tomados os cuidados devidos, podemos selecionar no menu de boot, a
versão antiga do kernel que salvamos antes de instalar o novo kernel. Podemos
simplesmente bootar o kernel antigo para tentar terminar a compilação do novo
e corrigir possíveis falhas ou tornar ao antigo novamente para o padrão, copiando
os arquivos sobre os novos gerados na instalação.
Um cuidado que não foi citado ainda é nunca compilar e testar um novo kernel
em uma máquina em produção. Imagine se colocasse o servidor de arquivos de
uma empresa fora do ar, por tentar voltar o kernel antigo. O mesmo princípio vale
para patch do Windows ou de qualquer sistema operacional:
a) realize todos os testes em uma máquina que não esteja em produção;
b) se não tivermos outra máquina para teste, podemos sempre instalar uma
máquina virtual, seja Xen, Virtualbox ou outra tecnologia, e testar o processo
de compilação ou de aplicação do patch no sistema operacional presente
nessa máquina virtual;
c) antes de aplicar as alterações, faça um snapshot da máquina virtual, isso
pode lhe poupar muito trabalho.
184
Fique atento: em um processo de recuperação do kernel antigo, não basta vol-

tar o arquivo vmlinuz antigo apenas, devemos voltar também os módulos, fir-
mware e reinstalar o bootloader.
Lembramos que a internet possui diversos grupos de usuários e listas de dis-
cussão sobre o sistema operacional Linux e você pode tirar proveito delas para
tentar resolver seus problemas ou dúvidas.
RECUPERAÇÃO DE BACKUP
Quando planejamos, as coisas ficam mais fáceis. Vamos supor que, por não ter
feito o backup devido antes da instalação do novo kernel ou pela sua perda, não
temos outro a não ser o novo que não funciona. O que fazer?
De posse do CD/DVD de sua distribuição, coloque-o no leitor e deixe bootar
como se fosse instalar o sistema, mas no menu principal use a opção:
Odirlei Batista
vmlinuz root=/dev/sdaxxx ro
Figura 133 - Opção a ser escolhida no menu principal
O kernel a ser carregado será o do CD de instalação, mas o diretório raiz onde

o boot continuará com o init será o sdaxxx (que deve ser substituído por sua par-
tição raiz). Após bootar desta forma, você terá acesso normal ao seu sistema e
poderá recompilar seu kernel de forma correta.
Observamos que, por mais que tenhamos sido atentos no processo de compi-
lação do kernel e sua instalação, podem ainda ocorrer falhas. Neste tópico, apre-
sentamos alguns exemplos e resoluções, caso ocorram essas falhas.
3.3. AUTOMAÇÃO DE TAREFAS UTILIZANDO-SE DE SCRIPTS
3.3.1 USO DE SCRIPTS
Vamos a um cenário interessante. Digamos que você precisa levar uma caixa de
uma cidade a outra. Dispõe de um carro, uma bicicleta e um avião ou pode ir andan-
do. Qual a melhor alternativa? Pensou? Um dado que não foi informado: a cidade
que você está e a outra são separadas apenas por uma rua e seu destino fica do ou-
tro lado desta, a 3 metros, e nela não é permitido estacionar carros, o mais próximo
fica 100m. A escolha agora parece óbvia, não? Esse pequeno exemplo nos ensina
que nem sempre a “melhor alternativa” é a melhor opção. Em informática também.
185
O INÍCIO
Os primeiros sistemas computacionais eram baseados em um modelo em que

o usuário não interagia com o sistema, apresentava o software e os dados e rece-
bia o resultado. Em uma fase inicial, decks de cartão eram usados. Evoluímos para
sistemas baseados em armazenamento secundário via disco e fita, tornando a
tarefa do operador menos árdua em colocar um programa para executar.
Um problema que surgiu e persiste na informática é a consolidação de esto-
que em lojas. O relato a seguir ilustra o problema das empresas Construções Feliz.
CASOS E RELATOS
O problema das empresas Construções Feliz

A empresa Construções Feliz começou, como empresa familiar, em que
Sr. José era o responsável por ser o balconista, caixa e ainda encomendar
os itens a fornecedores mantendo o estoque. As entregas da loja também
eram realizadas por ele em momentos de folga ou o cliente podia retirar
a mercadoria na loja.
Com o passar do tempo, a Construções Feliz cresceu, funcionários foram
contratados e diversas filiais foram abertas. Sr. José manteve apenas um
hábito como dono e gerente geral de sua empresa, o processo de com-
pra de materiais era mantido na matriz, pois comprando no atacado em
grandes quantidades sempre era mais barato. O grande problema era o
controle de estoque: por exemplo, quantos itens de cimento ainda exis-
tiam em todas as filiais? Notando a dificuldade, adotou-se um sistema de
vendas em que cada filial contava com um computador e, no final do expe-
diente, este enviava o arquivo para a matriz, onde um funcionário juntava
todos os arquivos das filiais, que fechava às 18h, e rodava o software de
processamento para gerar uma listagem de estoque e itens a comprar no
dia seguinte. A grande dificuldade é que a Construções Feliz tinha sede em
Goiânia (GMT-3) e filiais em diversos estados com zonas de tempo diferen-
tes, o que obrigava a espera do arquivo da filial do Acre (GMT-5).
A solução foi recorrer à automatização do sistema. Foi escrito um pro-
grama script usando o crontab do Unix que recebe todos os arquivos e,
quando disponíveis, a parte realizava o processamento devido, gerando
o resultado sem erros.
186
Nossa história ilustra bem o cenário a que chamamos processamento offline

ou batch. Não existe usuário envolvido, um programa computacional é responsá-
vel por automatizar as tarefas. E os usuários têm seus resultados de forma prática,
cômoda e eficaz.
Pense em esperar até as 22h apenas para apertar um enter e disparar um ba-
ckup em fita, já que a fita já foi montada na unidade e só falta começar o processo.
Não parece agradável a tarefa.
Existem muitos cenários em que a interatividade com o usuário, digitando co-
mandos em uma interface gráfica, não é necessário. Vamos discutir alguns e o
mecanismo de Crontab.
SCRIPTS
Um script consiste em um programa descrito em uma linguagem de progra-

mação interpretada (quase sempre) para a realização de tarefas padronizadas. Em
sistemas operacionais, temos as chamadas interfaces de acesso ao serviço desses
sistemas conhecidos como shells. Essas shells podem ser textuais ou gráficas (GUI
– Graphic User Interface). As shells são os principais interpretadores de comandos
empregados para se escrever scripts.
Se você olhar em sua distribuição Linux, encontrará diversos scritps.
Vamos a alguns:
a) no processo de login, por exemplo, podemos usar um script para depois do
login se montar o sistema de arquivo em rede no diretório do usuário. Isso é
muito usado tanto em ambiente Unix como Windows;
b) outra tarefa interessante é a de tratamento de logs. Se você faz uso de boas
práticas de segurança de acordo com a ISO 17799, logs de atividades são
essenciais. O problema dos logs é que eles crescem muito e lidar com ar-
quivos grandes gasta memória principal impactando no processamento dos
programas de usuário.
Uma alternativa interessante é todo dia pegar os arquivos (ou arquivos) com
logs e gerar uma cópia, comprimir e guardar, gerando um arquivo novo para o dia
seguinte. O problema é que isso deve ser feito em um momento que ninguém
está usando o sistema, por exemplo, três horas da manhã. E não existe ninguém
para iniciar a tarefa. O que fazer? Bom, fazer um script parece ser uma boa ideia,
mas como iniciá-lo às três da manhã? O crontab é a solução.
187
CRONTAB
O crontab (<http://www.adminschoice.com/crontab-quick-reference>) con-

siste em um aplicativo Unix que fica executando e podemos agendar tarefas.
O uso é muito simples e o obtemos com o man contrab. Na essência, podemos
agendar tarefas e removê-las, sendo que o agendamento pode ser para uma úni-
ca execução ou para várias.
Logue como root em seu sistema.
O comando crontab -l lista as tarefas agendadas, veja a seguir a saída típica.
root@aldeia3:~# crontab -l
47 * * * * /usr/bin/run-parts /etc/cron.hourly 1> /dev/null
40 4 * * * /usr/bin/run-parts /etc/cron.daily 1> /dev/null
Thiago Rocha
30 4 * * 0 /usr/bin/run-parts /etc/cron.weekly 1> /dev/null
20 4 1 * * /usr/bin/run-parts /etc/cron.monthly 1> /dev/null
Figura 134 - Saída de crontab -l
a) a linha em vermelho executa o script run-parts com o parâmetro cron.hourly

no minuto 47 de cada hora;
b) a linha em verde executa o script run-parts com o parâmetro cron.daily todo
dia às 4:40 da manhã;
c) a linha em violeta executa o script run-parts com o parâmetro cron.weekly
toda semana no primeiro dia da semana as 4:40;
d) a linha em rosa executa o script run-parts com o parâmetro cron.monthly no
primeiro dia de cada mês às 4:20 da manhã.
Da figura anterior, foram removidos os comentários (de forma a não ocupar
espaço), logo sua saída de comando será um pouco diferente, levando em conta
a distribuição em uso e o que está agendado, os da listagem são scripts básicos de
manutenção do Linux.
O comando crontab -e permite alternar as tarefas agendadas. Uma observação
é que essas tarefas são agendadas com a conta do usuário e com suas permissões.
Aprendemos, neste tópico, a importância de scripts em detrimento ao uso in-
terativo do computador em alguns momentos e como usar o crontab.
188
3.4 AMBIENTES SHELL
3.4.1 SHELL E VARIÁVEIS DE AMBIENTE
Imagine que, ao andar em um carro, você tivesse que entender tudo sobre mo-
tores e ser um expert em química, para lidar com combustíveis. Não que isso fosse
ruim, mas certamente poucas pessoas estariam aptas a dirigir um carro. Agora
pense que se todo usuário de computador tivesse de saber tudo de hardware
e sistema operacional. É melhor que o sistema operacional envolva o hardware
e nos forneça uma interface amigável de acesso a seus recursos. Assim, surge a
ideia de shell que discutiremos neste tópico.
A SHELL
Em 1972, com o lançamento do Unix, adotamos os modelos de camadas de

serviço, onde temos:
a) o núcleo do sistema operacional;
b) a API de serviço;
c) contornando esse ambiente equivale a uma capa de proteção.
Na época, a ideia de Kernigan e Ritchie (K&R), os desenvolvedores, foi nomear
essa camada (que permite o usuário interagir com o sistema operacional digitan-
do comandos) de shell (concha em inglês). O sistema operacional Unix como uma
pérola é protegido por essa concha. A figura a seguir apresenta essa ideia. Nela,
temos duas visões:
a) a primeira de que a única forma de acesso ao Unix é pelo Unix shell;
b) a segunda em se pode acessar os serviços, não só pela shell, mas por uma
gama de programas básico.
Podemos avaliar a segunda imagem como um refinamento da primeira.
189
Unix Users
Unix Shell
x Kernel
Uni
Computer
Hardware
Application
Programs
bash more
ksh pg
csh which
sh env
Hardware Mail
cpp cut
comp Kern el ed
as vi
DBMS S h e ll
Thiago Rocha (2012)
FTP
Figura 135 - Arquitetura do Unix em duas visões

Fonte: <http://www.tutorialspoint.com/images/unix_architecture.jpg e
<http://www.onestoptesting.com/images/unix-architecture.gif>
Se quiser conhecer mais sobre o Unix em sua fase inicial, visite a página de De-
nis Ritichie, um dos projetista dele junto com Ken Thompson, em <http://cm.bell-
-labs.com/who/dmr/>.
Uma shell consiste no que chamamos atualmente de interpretador de
comandos.
Um software que nos apresenta uma linha de comando onde digitamos coman-
dos e eles são implementados internamente na shell ou são aplicativos em disco.
190
Com o desenvolvimento do Unix feito na linguagem C, seria muito natural que

uma interface para digitarmos comandos para o sistema operacional seguisse a
sintaxe e se parecesse um pouco com o C.
A primeira shell, desenvolvida por K&R, é conhecida como C shell. A ideia do
emprego de uma interface de comando não era nova e foi prontamente absorvi-
da pelo mercado.
Os conceitos que conheceremos foram pensados no Unix, mas se aplicam a
sistema operacionais que tiveram o Unix como referência, estando aí o Microsoft
MS DOS e Microsoft Windows, bem como o Mac OS X.
Em primeiro lugar, a shell consiste em um local que podemos digitar coman-
dos, algo simples, mas na visão de K&R esse software deveria permitir também
escrever pequenos programas que facilitassem a execução de tarefas corriquei-
ras. Por exemplo, quando queremos mostrar uma mensagem como no quadro a
seguir, quando um usuário logar no sistema.
Quadro 3 - Exemplo de uso da shell
Bom dia ! se for entre 7-12

Boa Tarde ! se for entre 12:01-18:00
Boa noite ! nos demais casos.
Como a shell permite programação, podemos escrever um pequeno progra-

ma que verifique a hora e imprima a mensagem. Programa que será interpretado
pela shell, não necessitando ser compilado.
Esse pequeno programa é chamado de script (lembre-se de um script de uma
peça de teatro que tem o passo a passo: o que será realizado e quem o fará, em
analogia com o mundo).
O emprego de scripts para automação de tarefas no sistema operacional
é muito comum e está presente em quase todos os sistema operacionais. Um
exemplo é o rc.modules, que faz a carga de módulos para o kernel no Linux ou o
autoexec.bat, que executa aplicações ao ligarmos o computador com o MS DOS
da Microsoft.
VARIÁVEIS DE AMBIENTES E COMANDOS
Para termos programação, normalmente, necessitamos de alguns recursos,

como variáveis de trabalho e instruções. O conjunto de instruções disponíveis é a
sintaxe delas, variando de shell em shell.
Em relação a variáveis, temos dois tipos:
a) variáveis de trabalho: são definidas no script e serão tratadas pela shell:
191
b) variáveis de ambiente: são variáveis setadas para seu sistema operacional

ou um aplicativo específico.
No Linux ou no Windows, digite o comando set . Ele permite alterar o valor de
uma variável ou sem parâmetro imprimir a setagem atual de todas as variáveis.
Teste nos dois sistemas operacionais e observe a saída.
Um item importante é o PATH. Essa variável diz ao interpretador de comandos
onde encontrar o aplicativo cujo nome acabamos de digitar.
Vamos a um exemplo do Unix. Digamos que sua variável PATH está setada
conforme a figura a seguir:
PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/
Odirlei Batista
bin:/usr/games:/usr/lib/java/bin:/usr/lib/kde4/libexec:/usr/
lib/qt/bin:/usr/share/texmf/bin
Figura 136 - PATH típico no Unix/Linux
Os diretórios em que a shell tentará encontrar nosso programa são os itens da

lista separadas por dois pontos. Digamos que você mande executar o aplicativo,
teste. Se ele estiver no diretório /sbin será executado, mas se estiver em /opt/ss/,
aparecerá uma mensagem de arquivo não encontrado, visto que esse diretório
não está na lista de busca da shell.
Da mesma forma que o PATH existe, uma grande lista de variáveis setadas que
podemos observar quando usamos o comando set. Essas variáveis foram setadas
ou no boot da máquina para todo o sistema ou quando do login do usuário.
O uso é bem intenso por parte de aplicações. Temos como exemplo: o uso do
Java. Temos de instalar a Java Machine, JVM, mas para usá-la na documentação
do software necessitamos setar a variável JAVA_HOME para o diretório em que o
Java foi instalado. Essa variável é usada pela shell para executar módulos do Java.
Isso é comum entre aplicativos.
No Unix foram desenvolvidas diversas shell com sintaxes diferentes para escre-
ver scripts e comando, sendo as principais a sh (bourne shell), csh (c shell), ksh ( korn
shell), mas existem tantas outras menos usadas. No ambiente Microsoft, temos ori-
ginalmente o command.com no MS DOS e atualmente o cmd.exe no Windows.
GRAPHICAL USER INTERFACE
Com a popularização da GUIs (graphics user interfaces), uma série de ativida-

des que comumente eram realizadas via shell passaram a ser feitas via cliques
em ícones. Contudo, nos últimos anos, temos no processo de administração de
sistemas operacionais, em especial de servidor, o uso de scripts e shell em modo
192
texto, visto a grande produtividade que geram e a facilidade de acesso remoto

proporcionada por elas.
No sistema operacional Unix, incluindo o Linux, temos o uso conjunto com o
ssh, que permite abrir uma shell remota por meio de rede computacional em um
canal criptografado. No ambiente Windows, temos a adoção do power shell, que
permite atividade assemelhada às shells do Unix.
Aprendemos como usar num sistema operacional a shell, interpretador de
comandos que nos permite automatizar tarefas através de scripts. Descobrimos,
também, que as shells possuem instruções e variáveis internas e de ambiente.
3.4.2 SHELL SCRIPTS
Um script para shell, ou shell script, como chamamos, consiste em software

simples desenvolvido para ser executado em um interpretador shell do sistema
operacional. A sintaxe do shell script muda dependendo da shell empregada. Em
nosso exemplo, adotaremos o bourne shell (sh), bastante usado na automação de
tarefas no Linux.
Vamos estudar um script que consiste na implementação de nosso sistema de
saudação, bom dia, boa tarde e boa noite, identificando os diversos componentes
nele. O arquivo a seguir contém o seu código, você pode copiar e colar no seu
Linux para testar.
193
#!/bin/sh
# Descricao: script para saudação
# Autor: Garcia@computacao.net
# Versao: 0.1
echo "----------------------------------------------"
#mensagens de saudação a serem usadas
Dia="Bom dia, prezado usuário(a)!\n"
Tarde="Boa tarde, prezado usuário(a) !\n"
Noite="Boa noite, prezado usuário(a) !\n"
#obtém a data do sistema

horaf=`date`
#obtém o nome do usuário

eu=`whoami`
#imprime uma linha e a hora atual

echo "----------------------------------------------"
echo $horaf
#realiza a separação da hora da string hora e dia

horaa=`echo $horaf | awk '{print $4}'`
horaa=`echo $horaa | awk -F: '{print $1}'`
#define a mensagem
#se <12 dia, se > 18 noite senão tarde
if [ "$horaa" -lt 12 ]; then
Msg=$Dia
else if [ "$horaa" -gt 18 ]; then
Msg=$Noite
else
Msg=$Tarde
fi
fi
#imprime a saudação e o nome do usuário

Odirlei Batista
echo $Msg $eu

echo "----------------------------------------------"
Figura 137 - Script simples para saudação
Coloque o conteúdo da figura anterior em um arquivo com nome, por exem-

plo, teste, e o torne executável.
O Unix diferente do MS DOS e Windows não usa extensões como .exe ou .com
para dizer se um arquivo é executável, você deve fazer isso usando o comando:
Odirlei Batista
Chmod a+x teste
Figura 138 - Comando para tornar arquivo em executável

194
Ele tornará o script executável para todos. Teste, agora, digitando ./teste (o ./ é
para informar que o arquivo está no diretório corrente, se você estiver como root
o diretório corrente não está no seu PATH).
Vamos entendê-lo.
O arquivo começa com:
Odirlei Batista
#!/bin/ssh
Figura 139 - Linha informa que deve ser executada o sh.
A linha informa que deve ser executada a shell que vem depois do #!, neste
caso o sh.
# Descrição: script para saudação
Odirlei Batista
# Autor: Garcia@computacao.net
# Versao: 0.1
Figura 140 - Linha de comentário
Linhas que começam com # constituem linhas de comentário. Um script como

um software deve ter a devida documentação para quem for editá-lo e modificá-
-lo consiga entender o que faz.
O mínimo esperado é a descrição do que faz, o autor e a versão do software.
Comentários podem ser colocados ao longo do script, como mostram as outras
linhas começadas com #.
Tente manter também um bom espaçamento entre linhas e escolher nome de
variáveis significativas.
O restante do script consiste no código em si, fazendo uso tanto de coman-
dos internos da shell como a definição de variáveis e atribuição de valores como
nas linhas:
Dia="Bom dia, prezado usuário(a)!\n"

Odirlei Batista
Msg=$Dia
horaf=`date`
Figura 141 - Definição de variáveis e atribuição de valores
Na primeira linha, temos um exemplo de atribuição direta em que associamos

a string ao variável DDI; a segunda linha exemplifica uma variável recebendo o
valor de outra; e a última linha a variável recebendo o resultado do comando date,
veremos como.
195
USANDO COMANDO EXTERNO
Além dos comandos internos da shell, que envolvem os preceitos básicos de

programação como instruções para atribuição, lógicas, aritméticas e de controle
de fluxo de execução, podemos invocar (executar) aplicativos e obter seu resulta-
do para processamento na shell.
Em nosso exemplo, empregamos isso para obter a data e a hora, via comando
date e depois, já que o date volta uma string com mais informações do que que-
remos, usamos o processador de strings awk para a tarefa em duas linhas para
separar a hora.
Comandos externos são evocados, colocando-os entre ` quando queremos
pegar sua saída ou simplesmente colocando o comando no script. Podemos notar
isso no exemplo a seguir.
#!/bin/sh
# Descrição: script para fazer backup do /etc
# Autor: garcia@computacao.net
#versao: 1.0
Data=`date`
Nome=backup-etc-$Data.tar
Echo “Realizando Backup de /etc em “ $Nome
Tar –cf $Nome /etc
ls –l $Nome
Figura 142 - Script de backup
Neste caso, usamos o date para gerar a string e os comandos tar e ls para rea-
lizar ações.
O if presente na tomada de decisão é um exemplo de comando interno, da
mesma forma que o echo.
Ao terminar o script, ele encerra o processo sh (no nosso caso) e volta para o
aplicativo que invocou nosso script.
VARIÁVEIS DE AMBIENTES
Você deve ter notado que não setamos as variáveis PATH e outras importan-
tes. Se elas não foram alteradas, o valor que está setado no aplicativo que exe-
cutou nosso script é empregado. Mudança em variáveis do sistema só têm valor
dentro do script.
Vamos verificar o contexto local de variáveis.
196
Digite:
Odirlei Batista
Cd /
Figura 143 - Comando Cd /
No sh digite env e analise o valor de PATH. Certamente estará setando com

uma série de valores, entre eles /bin ou /usr/Bin, que contém aplicativos-chave,
como o comando ls, que lista os arquivos em disco.
Digite ls.
Funcionará como pode ser visto a seguir.
root@slvm:/# ls
bin/ boot/ dev/ etc/ home/ lib/ lost+found/ media/ mnt/
Odirlei Batista
opt/ proc/ root/ sbin/ srv/ sys/ tmp/ usr/ var/
root@slvm:/#
Figura 144 - Comando ls
Agora abra uma nova shell digitando sh e digite set PATH=/etc e verifique se
foi modificado como a seguir.
Sh
Echo $PATH
Odirlei Batista
PATH=/etc
Echo $PATH
Figura 145 - Resultado de set PATH=/etc
Digite ls.
O que conseguiu?
root@slvm:/# ls
Odirlei Batista
sh: ls: command not found

root@slvm:/#
Figura 146 - Resultado de ls
A mensagem se deve a nossa shell não ter encontrado o ls como comando

interno nem no /etc, contudo essa alteração no path só vale na shell em execução.
Digite exit (que termina o programa corrente), agora digite ls e funcionará no-
vamente:
197
root@slvm:/# exit
exit
Odirlei Batista
root@slvm:/# ls
bin/ boot/ dev/ etc/ home/ lib/ lost+found/ media/ mnt/
opt/ proc/ root/ sbin/ srv/ sys/ tmp/ usr/ var/
Figura 147 - Resultado encontrado
Ambos os scripts apresentados são muito simples, mas ilustram bem a lógica
de desenvolvimento.
Neste tópico, você aprendeu como desenvolver um script analisando exem-
plos e comparando com sua atividade em seu computador.
3.4.3 SHELL SCRIPTS - PREEXISTENTES
Se você coordenar uma determinada tarefa, a primeira vez que for realizada
certamente será interessante que acompanhe sua execução. Contudo, se toda
vez que a atividade for realizada, depois de padronizada, e não fizer parte da exe-
cução, apenas da supervisão, isso será repetitivo e sua participação poderia ser
apenas verificar o resultado final.
Em informática da mesma forma, tarefas corriqueiras podem ser automatiza-
das mediante o uso de scripts, ou shell scripts, como os chamamos. Diversos scripts
já existem em uma instalação Linux, vamos conhecê-los neste tópico.
O PRIMEIRO SCRIPT
O sistema operacional Linux, após seu boot, tendo o kernel colocado em me-
mória, executa o programa init, que verifica as setagens em /etc/inittab e inicializa
o sistema operacional carregando os demais aplicativos. Ele pode inicializar em
modo com suporte à rede, mono ou multiusuário. Então, apresenta ao usuário
final uma tela de login que pode ser gráfica ou a linha de comando do prompt via
comando login.
É importante que o passo a seguir iniciado pelo init seja definir qual script será
executado a seguir.
Vamos a um exemplo pegando a distribuição CentOS muito utilizada em ser-
vidores e Linux appliances (Linux customatizado para uma determinada função).
Vejamos o arquivo inittab:
198
# Default runlevel. The runlevels used by RHS are:

# 0 - halt (Do NOT set initdefault to this)
22 Evocado
# 1 - Single user mode
# 2 - Multiuser, without NFS (The same as 3, if you do not
Chamado.
have networking)
# 3 - Full multiuser mode
# 4 - unused
# 5 - X11
# 6 - reboot (Do NOT set initdefault to this)
#
id:5:initdefault:
# System initialization.
si::sysinit:/etc/rc.d/rc.sysinit
l0:0:wait:/etc/rc.d/rc 0

Figura 148 - Inittab em CentOS 5.6
Podemos notar a preocupação com a documentação dos níveis de uso, ressal-

tando de forma clara a utilidade de documentar scripts.
A inicialização está setada em 5, que é o modo X11, e a seguir (marcamos em
vermelho) você vê a linha que será executada: o script /etc/rc.d/rc com parâmetro 5.
Se você possui uma cópia de CentOS, poderá notar os demais scripts em
/etc/rc.d.
Vejamos agora outra distribuição; um Slackware 13.37.
# These are the default runlevels in Slackware:

# 0 = halt
# 1 = single user mode
# 2 = unused (but configured the same as runlevel 3)
# 3 = multiuser mode (default Slackware runlevel)
# 4 = X11 with KDM/GDM/XDM (session managers)
# 5 = unused (but configured the same as runlevel 3)
# 6 = reboot
# Default runlevel. (Do not set to 0 or 6)

id:3:initdefault:
# System initialization (runs when system boots).

si:S:sysinit:/etc/rc.d/rc.S
# Script to run when going single user (runlevel 1).

su:1S:wait:/etc/rc.d/rc.K
# Script to run when going multi user.

rc:2345:wait:/etc/rc.d/rc.M
Figura 149 - Inittab em Slackware 13.37

199
Neste, podemos ver que o modo default é o 3, sendo que o script evocado22 é
o /etc/rc.d/rc.M, diferente do que aconteceu no CentOS.
As mudanças nas diversas distribuições, mesmo executado a mesma versão de
kernel, começa no init. Se você visitar, no caso do exemplo anterior, o /etc/rc.d,
encontrará os outros scripts padrões do Slackware.
Os principais scripts se referem à carga de módulos, setagem de rede e sistema
de arquivo em rede, bem como interface gráfica. Para conhecê-los, leia a docu-
mentação de sua distribuição.
Aprendemos que existem diversos scripts padrões e como o processo de carga
começa com o init, bem como existim diferenças entre distribuições.
3.4.4 SHELL SCRIPTS – DESENVOLVER
Além de entender e alterar scripts do sistema operacional, desenvolver seus

próprios scripts podem facilitar muito seu trabalho no dia a dia. Vamos desenvol-
ver, neste tópico, um script com o bourne shell.
O SCRIPT
Nosso desafio será ler nome de um diretório, comprimi-lo e imprimir o nome

do arquivo gerado no final. Como elemento de apoio, empregaremos as seguin-
tes ferramentas para o trabalho:
a) tar para gerar o arquivo imagem do diretório;
b) dd para gerar a imagem de uma partição;
c) gzip2 para comprimir a imagem;
d) mkisofs para gerar um arquivo para gravar em cd;
e) awk para processar strings;
f) sh shell Linux.
Nosso script será denominado backup.sh.
Basicamente, nosso script é a expressão dos comandos que digitaríamos no te-
clado, mas são colocados num arquivo por comodidade como no passo a passo:
a) ler o nome do diretório a fazer backup;
b) verificar se o diretório existe;
c) gerar um nome de arquivo para o backup (nome diretório + data);
d) gerar o tar do diretório;
200
e) comprimir o tar com gzip2;

f) imprimir o nome do arquivo gerado para o usuário final e caminho para ele.
PASSO 1: LER O NOME DO ARQUIVO
Uma alternativa mais interessante que ler o nome do arquivo é passá-lo como
um parâmetro para o script. O seja o script será invocado como:
Odirlei Batista
backup.sh nome_arquivo
Figura 150 - Invocar o script
Programas no Unix tratam o $0 como o nome do aplicativo (no caso backup.

sh) e $1, $2 e assim por diante os demais itens separados por espaço.
PASSO 2: VER SE O DIRETÓRIO EXISTE
Antes de gerar o arquivo tar do diretório, devemos ver se ele existe. Podemos
usar o test para testar se existe o arquivo e se não existir, imprimir uma mensa-
gem e sair.
if test -f $1
Odirlei Batista
echo “ diretório não existe !”
exit 1
Figura 151 - Comando test
PASSO 3: GERAR O NOME DO ARQUIVO DE BACKUP
Aqui podemos usar o date para gerar o nome do arquivo, lembrado que o $1
tem o nome do arquivo.
Odirlei Batista
Data=`date`
Nome=$1$Data.tar
Figura 152 - Comando date

201
PASSO 4: GERAR O tar DO ARQUIVO
Atividade simples, basta usar tar. Um cuidado é gerar esse arquivo em /tmp
e trabalhar lá só colocando no diretório corrente quando terminarmos a tarefa.
Odirlei Batista
tar -cvf /tmp/$Nome $1
Figura 153 - Comando tar
PASSO 5: COMPRIMIR
Podemos comprimir em diversos formatos, empregaremos o bz2,
Odirlei Batista
gzip2 /tmp/$Nome
Figura 154 - Comando bz2
PASSO 6: COLOCAR O ARQUIVO NO DIRETÓRIO CORRENTE E IMPRIMIR

UMA MENSAGEM
Odirlei Batista
mv /tmp/$Nome.bz2 .
echo “backup com sucesso no arquivo: “ $Nome.bz2
Figura 155 - Colocando o arquivo no diretório
Juntando as partes, você obterá o script a seguir.

202
#!/bin/sh
# Descrição: script para fazer backup de diretório
# uso backup.sh nome-diretório-a-realizar-backup
#versao: 1.0
# ve se diretório existe
if test -f $1; then
echo “ diretório não existe !”
exit 1
fi
#gera o backup tar em /tmp

Data=`date`
Nome=$1$Data.tar
tar -cvf /tmp$Nome
#comprime
bzip2 /tmp/$Nome
#termina
mv /tmp/$Nome.bz2 .

echo “backup com sucesso no arquivo: “ $Nome.bz2
# msg ok
exit 0
Figura 156 - Script obtido
Teste o script com seus arquivos para ver se funciona. De que adianta um script
de backup se não conseguimos voltar a ele? A seguir, você encontra o script res-
tore.sh que tem dois parâmetros, o primeiro o arquivo tar.bz2 e o segundo o di-
retório onde será colocado, use com cuidado para evitar sobreposição de dados.
A ideia básica é a mesma:
a) validade os parâmetros se o nome e diretório existem;
b) descomprima o arquivo;
c) desempacote o arquivo;
d) avise o usuário.
203
#!/bin/sh
# Descrição: script para fazer restauração de backup de diretório
# uso restore.sh nome_arq_backup diretório_destino
#versao: 1.0
# ve se diretório e arquivo existem

if test -f $2; then
echo “ diretório destino não existe !”
exit 1
else if test -f $1; then
echo “ arquivo de backup não existe!”
exit 1
fi
fi
#descomprime e desempacota
cp $1 $2
cd $2

tar -xvjf $1
rm $1
exit 0
Figura 157 - Script restore.sh
Se analisarmos os scripts anteriores, veremos que eles podem ser otimizados,

fazendo a tarefa de forma mais eficaz. Essa é uma vantagem, sempre podemos
melhorá-los. Lembramos que para o script ser executável devemos usar o coman-
do: chmod a+x no arquivo.
No site <http://www.csie.ntu.edu.tw/~r92092/ref/win32/
SAIBA win32scripting.html >, há um bom tutorial com exemplos de
MAIS como trabalhar com MS DOS e <http://www.mvps.org/scrip-
ting/> para Windows scripts.
O desenvolvimento de scripts no Windows funciona de forma semelhante ao

Unix, contudo os arquivos devem ter a extensão .bat, de batch ou lote em refe-
rência a execução não interativa.
Mostramos, neste tópico, como desenvolver um script para um problema es-
pecífico e como reutilizá-lo. Com essas informações, você poderá desenvolver
scripts para suas tarefas corriqueiras.
204
3.5 CONTAS E PERFIS DE USUÁRIOS LOCALMENTE

23 Premissas
Ideia ou fato inicial de que

se parte para formar um 3.5.1 POLÍTICA DE SENHAS
raciocínio ou um estudo.
Se a segurança de nossa infraestrutura está relacionada com um mecanismo
de autenticação em que nós identificamos e apresentamos uma senha, é muito
importante que nossas senhas sejam fortes, dentro de uma política institucional.
O requisito segurança da informação é normatizado e tratado pelas NBR ISO
IEC 17799:2005 e NBR ISO IEC 27002:2008, parte da série 27000.
Uma questão importante que marca e leva a existência da norma 17799 é a ne-
cessidade de gestão da segurança da informação nas empresas de forma sistêmi-
ca e padronizada. Para tal, um elemento apresentado como essencial é a existên-
cia de uma política de segurança e, dentro desta, um item essencial é o controle
de acesso, estando localizado o requisito da política de senhas.
Sabemos que as senhas são as chaves de acesso a nossos dados e recursos.
Fica clara a necessidade de termos senhas-chave fortes e os cuidados com elas,
como previsto na norma 17799. Em especial, citamos algumas regras essenciais:
a) não usar dados pessoais em senha;
b) ter tamanho mínimo;
c) misturar letras, caracteres e símbolos;
d) ter um tempo máximo de uso, ou seja, serem trocadas voluntariamente ou
expirar em determinado momento;
e) política de confidencialidade de senhas: não sejam passadas para terceiros,
para uso ou a título informativo (é de uso pessoal e pronto).
Os sistemas operacionais tentam implementar essas premissas23, mas pode-
mos ignorá-las. Após o estabelecimento de políticas de senha, devemos imple-
mentá-las. Se estamos executando um serviço em uma empresa ou indústria, de-
vemos estar atentos ao criar contas de usuários.
Mostramos, neste tópico, que devemos levar em conta a normatização de se-
gurança e as práticas da empresa para estabelecer uma política de senhas.
3.5.2 CRIAÇÃO E REMOÇÃO DE CONTAS LOCAIS
Segurança é importante. Seja no mundo real, seja no virtual. Atualmente, es-

tamos na chamada convergência digital, em que nossas mídias tradicionais trans-
formaram-se em digitais.
205
É muito clara a necessidade de segurança no mercado representada pela tría-

de CIA (confidencialidade, integridade e disponibilidade). Para implementarmos
o requisito confidencialidade, é essencial que somente pessoas que tenham direi-
to ao acesso à informação (seja para leitura, escrita ou ambos) o façam.
Para tal, realizamos a identificação dos usuários, a sua autenticação, e lhe da-
mos autorizações.
A autenticação de usuários se dá tipicamente por meio de senhas, certificados
digitais, biometria, entre outros meios, garantindo que os usuários são realmente
quem dizem ser.
O sistema operacional desempenha papel-chave na questão da confidenciali-
dade, por ser a porta de acesso aos recursos computacionais. Logo, o processo de
autorização é realizado e a autenticação é implementada no sistema por meio de
contas de acesso. Vamos discutir, neste tópico, o processo de criação de contas
de usuário na máquina local.
Você pode aprofundar mais seus conhecimentos sobre segurança da informa-
ção, em especial sobre a tríade CIA e política de segurança, lendo a Norma NBR
ISO IEC 17799:2005.
A partir da adoção de sistemas operacionais multiusuários, passamos a usar o
sistema de autenticação com nome de usuário para garantir sua identidade, pro-
teger seus arquivos e processos em execução, entre outros recursos. No modelo
clássico, temos o computador visto como isolado, sem conexão à rede, em que
devemos criar uma conta para o usuário trabalhar localmente. Essa conta permite
usar o computador em caso de queda da rede computacional. Esse processo é
comum tanto no Linux como no Windows.
Uma segunda possibilidade que evoluiu é a do uso de autenticação em um
servidor de autenticação via rede computacional. Entendemos que os recursos
são compartilhados na rede e a autenticação deve ser centralizada. Diversas abor-
dagens foram adotadas ao longo do tempo, sendo as principais o NIS (Network
Information System) no Unix e o mecanismo de autenticação via controlador de
domínio com PDC e BDC no Windows.
Nos sistemas atuais, trabalhamos com o conceito de serviço de diretório que
integra no autenticador bem mais informações do perfil do usuário, além da se-
nha e do nome de usuário, a referência básica aqui é o padrão X.500 (<http://
www.x500standard.com/ >).
No ambiente Linux/Unix, o caminho tem sido o uso do software LDAP e no Win-
dows do AD (Active Directory). Contudo, em ambos os casos, precisamos de aces-
so de administrador da rede para criar contas nos servidores de diretório, o que
algumas vezes não sabemos se lidamos com manutenção e suporte em informá-
tica. A solução consiste então em partirmos para a criação de contas locais. Vamos
206
discutir como fazer isso no Windows e Linux. Primeiramente, devemos ressaltar

que existem diversos perfis de usuário no sistema, dentre eles o administrador.
CONTAS NO WINDOWS
No Windows 7, a criação de conta é feita logando como administrador da má-

quina. No painel de controle, clique em Painel de Controle e em Contas de usuá-
rio e segurança familiar.
Thiago Rocha (2012)

Figura 158 - Painel de controle no Windows
Após clicar em criar a conta, você estará de volta ao menu Iniciar. Clique sobre
a conta que acabou de criar. Você pode escolher a senha da conta e uma imagem
para identificá-la.
Fique atento e utilize uma senha forte.
Vamos testar. Crie uma conta chamada teste e logue com ela.
Agora, selecione em conta de usuário, adicionar ou remover contas de usuário
e terá a tela a seguir, onde estão listadas as contas existentes e a possibilidade de
criar uma nova conta. Clique em criar nova conta.
207
Thiago Rocha (2012)

Figura 159 - Listagem de contas no Windows
Clique em Criar uma nova conta. Você pode escolher nome de usuário e perfil
da conta padrão ou administrador. Escolha com cuidado, já que uma conta ad-
ministrador pode acessar qualquer recurso da máquina e alterá-los, o que não
desejamos algumas vezes.
Thiago Rocha (2012)
Figura 160 - Criando uma conta no Windows
Agora, se quiser, pode apagar a conta criada. Logue como administrador e, no

menu de Contas de usuários, clique novamente em adicionar ou remover conta
de usuário. No menu, selecione a conta, teste clicando nela, agora escolha Excluir
a conta (veja a figura a seguir), onde o alerta sobre excluir os arquivos do usuário
surgirá. Em um cenário real, sempre realize backup dos arquivos antes de apagá-
-los. Note a observação de que o Windows pode manter apenas uma parte dos
documentos do usuário.
208
Thiago Rocha (2012)

Figura 161 - Alerta sobre exclusão de arquivos no Windows o menu
CONTAS NO LINUX
No Linux, existem diversas possibilidades de criação de contas. Como usar o

aplicativo KUser do KDE (a figura abaixo mostra um exemplo) ou outra solução de-
pende do gerenciador de janelas, de forma assemelhada ao ambiente do Windows.
Thiago Rocha (2012)
Figura 162 - Uso do KUser para criar contas no Linux
Em nossa prática, empregaremos os aplicativos de linha de comando que aca-

bam sendo invocados pela interface gráfica.
No Linux, o processo de criação de novas contas envolve o comando adduser,
vamos testar.
Você deve estar logado como administrador para o procedimento.
Digite su root e informe a senha ou logue como root.
Digite adduser.
Uma série de itens serão questionados sobre o novo usuário, sendo que em al-
guns o campo pode ser deixado em branco. Vamos criar a conta teste que expira
em 31-12-2012.
209
A figura a seguir apresenta um resumo do que verá ao executar o comando

adduser com os campos que serão preenchidos em vermelho.
Note que o aplicativo nos ajuda, informando helps sobre grupos adicionais no
Unix e sobre senhas fracas.
Após a criação da conta (creating new accounting), você poderá fornecer dados
pessoais opcionais, como sala etc.
root@slvm:~# adduser
Login name for new user []: teste
User ID ('UID') [ defaults to next available ]:
Initial group [ users ]:
Additional UNIX groups:
Users can < … recortado …> groups:
Home directory [ /home/teste ]
Shell [ /bin/bash ]
Expiry date (YYYY-MM-DD) []: 2012-12-31
New account will be created as follows:
---------------------------------------
Login name.......: teste
UID..............: [ Next available ]
Initial group....: users
Additional groups: [ None ]
Home directory...: /home/teste
Shell............: /bin/bash
Expiry date......: 2012-12-31
This is it... if you want to bail out, hit Control-C.
Otherwise, press ENTER to go ahead and make the account.
Creating new account...
Changing the user information for teste

Enter the new value, or press ENTER for the default
Full Name []: Conta de teste
Room Number []: Sala 01
Work Phone []: +55 62 9999999
Home Phone []:
Other []:
Changing password for teste
Enter the new password (minimum of 5 characters)
Please use a combination of upper and lower case letters and
numbers.
New password:
Bad password: too short.
Warning: weak password (enter it again to use it anyway).
New password:
Re-enter new password:
passwd: password changed.
Account setup complete.
Figura 163 - Criando uma conta com adduser no Linux

210
O item senha deve ser redigitado para garantir que não erramos na primeira
digitação, e não é mostrado por questões de segurança.
Para trocar a senha da conta, você pode usar o comando passwd, teste após a
criação da nossa conta de teste.
Vamos agora apagar a conta. Podemos usar o Kuser para isso ou na linha de
comando o userdel, o caso:
Odirlei Batista
userdel –r teste
Figura 164 - Apagar a conta
A opção –f informa que desejamos apagar os arquivos do usuário. Ae quiser-

mos que não seja pedida confirmação ao apagar os arquivos, acrescentamos a
opção –f (o comando seria userdel –r –f teste).
Repita o procedimento criando a conta teste em sua máquina e apagando-a
depois.
A opção –f pode ser cômoda, mas pode gerar grandes problemas dependen-
do de onde for usada, por não ter volta.
Mostramos, neste tópico, como criar contas e apagá-las no Linux e Windows.
Você aprendeu a importância desse procedimento na segurança da informação.
3.5.3 PROTEÇÃO DE ARQUIVOS VIA ACL
Nossos arquivos são os principais ativos ou bens em um ambiente computa-

cional. O que vale mais: o disco rígido de um computador ou nossas fotos pes-
soais (sem backup) dos últimos cinco anos? Acreditamos que as fotos. Manter o
acesso a esse recurso é muito importante, o acesso seguro mais ainda.
O sistema operacional é o elemento-chave para implementar controle de
acesso e proteção aos arquivos, sendo que existem duas grandes abordagens de
proteção a eles, por usuário ou por lista de acesso. Vamos aprender, neste tópico,
algumas abordagens de controle de acesso.
O sistema operacional Unix, na década de 1970, introduziu a abordagem de
proteger os arquivos em um esquema que envolve estabelecer o papel de dono,
grupo e todos.
Ao executar um comando ls –l, você verá essas permissões. Com esse mecanis-
mo, podemos setar permissões para o dono do arquivo ler, escrever ou executar
um arquivo (RWX). O mesmo conceito se aplica ao grupo que o arquivo pertence
e finalmente para todos os demais usuários do sistema. Esse mecanismo permite
211
como setar um arquivo com permissão de leitura, escrita e execução para o dono,
leitura e execução para o grupo e nenhuma permissão para os demais usuários,
neste caso não poderão acessar o arquivo.
SAIBA Sobre o sistema de proteção do Unix lendo o excelente livro

“The Design of the Unix Operating System”, de Maurice J.
MAIS Bach, um dos projetistas do Unix na AT&T.
ACL
Esta solução se mostrou bastante eficaz ao longo da década de 1970 e 1980.

Mas ao longo do tempo notou-se que seria mais interessante trabalharmos prote-
ção, não só em nível de máquina e de sistema operacional, mas também de cada
arquivo. A ideia foi passar a trabalhar com listas de controle de acesso ACL (access
control list) ligada a cada objeto arquivo no sistema.
A ideia base consiste em termos um arquivo quando o criamos como um con-
junto de permissões default (padrão), setas no sistema operacional e colocar essas
permissões ligadas ao descritor do arquivo, depois inserimos diversos nós na lista
de permissões para cada novo usuário que possa fazer algo com o arquivo, bem
como grupo.
O sistema operacional Windows NT nasceu na década de 1990 com a imple-
mentação de ACL como mecanismo de controle de acesso. Não vamos interpre-
tar que o Windows possui uma implementação melhor de controle de acesso,
apenas foi implementado 20 anos depois do Unix apropriando-se das experiên-
cias e mudanças que foram sendo propostas em sistemas operacionais. O Unix,
da mesma forma, implementa ACL como mecanismo de controle de acesso a ar-
quivos, sendo opção do usuário/administrador usar esse tipo de configuração.
O Linux, como implementação simplificada do Unix, baseada no Minix, em
suas primeiras versões de kernel suportava apenas controle de acesso padrão por
sistema operacional. Contudo, no kernel, corrente e sistemas de arquivo correntes
apresenta suporte pleno a ACL, bastando o usuário fazer uso.
Vimos, neste tópico, que a proteção a arquivos é importante. Também apren-
demos como podemos fazer, ressaltando a tendência no uso de ACLs.
212
3.6 GERENCIAMENTO E MANUTENÇÃO
3.6.1 PLANEJAMENTO DE MANUTENÇÃO E GERÊNCIA EM SISTEMA

OPERACIONAL E FERRAMENTAS PARA AUXÍLIO NO GERENCIAMENTO
“– Você poderia me dizer, por favor, por qual caminho eu deveria ir a

partir daqui?”
“– Depende muito de onde você quer chegar”, disse o Gato.
“– Eu não ligo muito aonde”, disse Alice.
“– Então não importa por qual caminho você quer ir”, disse o Gato.
“ – Desde que eu chegue a ALGUM LUGAR”, Alice adicionou, explicando.
“– Oh, você com certeza chegará”, disse o Gato, “– se você caminhar o
suficiente.”
O trecho anterior faz parte da obra “As aventuras de Alice no país das mara-
vilhas”, de Lewis Caroll, e reflete algo simples. Se desejo chegar a algum lugar,
para escolher o caminho, devo saber aonde quero chegar. Simples assim. Vamos
para outro mundo? Se desejo gerenciar os recursos de uma máquina por meio do
gerenciamento e da manutenção em um sistema operacional, devo saber o que
quero fazer. Visto que os dados são muitos, a presença e o uso de ferramentas
adequadas tornarão nossas decisões mais simples e precisas.
Gerenciar o sistema operacional é importante, mas devemos pensar no geren-
ciamento dele como um todo. A visão de gerenciamento integrada e fazendo uso
de outras áreas é a chave. Deste modo, neste tópico, vamos aprender algumas
possibilidades interessantes.
PLANEJAMENTO E MANUTENÇÃO
Pela conhecida lei de Murphy, se algo vai dar errado, sempre dará errado no
pior momento possível.
A nos depararmos com a necessidade de manutenção do sistema computa-
cional, temos as duas possibilidades:
a) a planejada, na manutenção preventiva: temos a oportunidade de plane-
jar para a realização da tarefa de manutenção no melhor momento e com os
recursos adequados;
b) a não planejada, no tratamento de falhas: devemos nos limitar à volta do
sistema ao ar o mais rápido possível com estabilidade e segurança, para isso
ações diárias ajudam muito no momento de crise.
213
Em uma manutenção, lembramos que, se o sistema estava funcionando, deve

continuar funcionando plenamente após ela. Diversos cuidados podem ser toma-
dos para garantir essa atividade de forma tranquila:
a) antes de realizar qualquer manutenção que envolva instalação ou remoção
de pacotes ou software de um sistema operacional, tenha certeza de ter feito
um backup, de modo que possa voltar ao ponto anterior se algo acontecer
de errado;
b) nunca realize procedimentos de manutenção com o sistema computacio-
nal em produção. Você pode ter tanto sucesso ou por ter, exemplo, um mero
patch no Windows rebootando a máquina levando o usuário à insatisfação.
Ter certeza que se você precisar ficar com a máquina indisponível para o
usuário por um determinado tempo não causará transtornos;
c) teste sempre seus procedimentos em ambiente de teste antes de aplicá-los
no ambiente de produção tendo certeza que vão funcionar.
O uso de ferramentas de apoio à gerência do sistema operacional e de gestão
do ambiente computacional pode ajudar muito. Lembremos então de algumas.
BACKUP
Backup é um elemento-chave da política de segurança da empresa, onde de-

vem estar claros os procedimentos de backup e a periodicidade. Para a realização
de backup, devemos empregar uma ferramenta adequada que permita tanto um
backup completo como um backup incremental.
Existem no mercado ferramentas e hardware de backup com facilidades de cus-
to muito baixo ao muito alto. Basta escolher o que se adapta às suas necessidades.
No ambiente Windows, encontraremos uma ferramenta de backup nativa que
apresenta boa funcionalidade. No ambiente Linux, existem diversas ferramentas,
merecendo destaque o Bacula (<http://www.bacula.org>), por ser open source e
sem custo, e o Arkeia (<http://www.arkeia.com>), uma solução comercial para
backup em rede e com suporte a vários aplicativos e plataformas.
Independentemente do software ou da tecnologia de armazenamento empre-
gada, é importante que os backups sejam realizados e mantidos em local seguro,
permitindo a restauração devido a uma falha de hardware, de software ou huma-
na na realização de uma tarefa, como, por exemplo, a aplicação de um patch mal-
sucedido no Windows ou uma compilação de kernel que não funcionou no Linux.
214
SNMP (Simple Network Management Protocol)
Se a empresa emprega uma plataforma de gerenciamento SNMP, podemos

integrá-la ao gerenciamento da coleta de informação do sistema operacional. Te-
mos tanto agentes SNMP para o sistema operacional como para as aplicações.
Diversas plataformas existem no mercado com suporte a SNMP. Como exemplos,
temos o zabbix (<http://www.zabbix.org>).
GERENCIAMENTO DE CONFIGURAÇÃO
Certamente nos deparamos com ambientes com muitas máquinas em que é

difícil realizar o gerenciamento de qualquer hardware e software existentes em
cada máquina. Encontramos no mercado soluções que lidam com esse desafio.
Podemos citar o SMS (Microsoft System Center), no ambiente Windows, e o proje-
to CACIC (Configurador Automático e Coletor de Informações), bem mais simples
que o SMS e é desenvolvido no Brasil para essa atividade.
O CACIC pode ser visto em <http://www.softwarepublico.gov.br/ver-
-comunidade?community_id=3585> e constitui uma solução muito usada não
somente no Brasil como na América do Sul.
SIEM
SIEM é uma denominação para Security Information Event Management, ou

gerenciamento de evento e informação de segurança, que são plataformas que
tentam juntar o máximo possível de dados sobre a rede computacional e seus
equipamentos, incluindo os computadores, em uma base central de informações,
onde se possa ter claro o estado do sistema, para decidir sobre o que fazer e como
fazer, incluindo procedimentos de manutenção.
Existem soluções bem interessantes, como o OSSIM (Open Source Security
Information Management - <http://communities.alienvault.com/community>)
aberto e padrão de fato na área.
Existem diversas outras ferramentas de auxílio, tanto as nativas do sistema
operacional como os elementos de manutenção e teste de terceiros, em especial
para diagnóstico de falha.
Devemos estar atentos às novas ferramentas que surgem no mercado e
como podemos utilizá-las para auxiliar na tarefa de administração do sistema de
computação.
215
Aprendemos, neste tópico, que na tarefa de administração do sistema opera-

cional quanto mais informações tivermos melhor, e listamos diversas ferramentas
que podemos utilizar para aperfeiçoar nosso trabalho.
3.7 FERRAMENTAS E ACESSÓRIOS DE SISTEMAS VISANDO ÀS

FUNÇÕES DE CONFIGURAÇÃO
3.7.1 FERRAMENTAS PARA ADMINISTRAÇÃO WINDOWS 7
Administrar é muito importante. Administrar de forma adequada e com uso

racional dos recursos é uma arte.
O sistema operacional devidamente parametrizado e instalado fará a gestão
dos recursos do hardware de forma adequada e permitirá seu bom uso. Pense em
administrar o sistema operacional; o software que gerencia os demais recursos é
sua atividade principal e essencial.
Conceituaremos, neste tópico, algumas ferramentas disponíveis para a gestão
do sistema operacional Windows 7, certamente algumas delas já são de seu co-
nhecimento.
FERRAMENTAS NATIVAS
A Microsoft agrupa as ferramentas de administração do Windows no Painel

de Controle (control panel). Essas aplicações serão acessadas em locais diferentes,
seja linha de comando ou via desktop, mas estão integradas e exibidas no painel
de controle, por área funcional (categoria). Podemos ver todas clicando no item
no topo da página.
A figura a seguir apresenta a tela do painel de controle do Windows 7 Ultimate
e seus componentes.
Thiago Rocha (2012)
Figura 165 - Painel de controle por categoria

216
Podemos notar o agrupamento pelos itens:

a) sistema e segurança: encontramos os aplicativos de suporte ao Windows
e de gestão de segurança. Temos o suporte a Firewall (do Windows). O item
Sistema permite obter informações sobre sua instalação e hardware, tendo
um link para gerenciador de dispositivos. O Windows Update controla como
o sistema realizará as atualizações. O item Gerenciamento de energia é im-
portante em notebooks, especialmente por permitir o ajuste do uso de har-
dware, mas ajusta também itens como screensaver;
b) backup e restauração: são essenciais, pois permitem lidar com os backups
no Windows, e da mesma forma com o item seguinte, Criptografia de disco.
Esse item autoriza a implementação da criptografia em partições Windows
usando o bitlocker. Essa característica implementa o requisito de confiden-
cialidade do dados. Existem diversas opções para criptografia de disco e par-
tições. O truecrypt consiste em uma alternativa flexível e de código livre.
Teste-a em <http://www.truecrypt.org >.
Entre no subitem ferramentas administrativas. Veja figura a seguir.
Thiago Rocha (2012)
Figura 166 - Ferramentas administrativas no Control panel
Nas ferramentas administrativas, há funções essenciais que devemos conhecer:

a) agendador de tarefas: consente, a exemplo do crontab no Unix, agendar
tarefas;
b) configuração do sistema: deixa ajustar o sistema operacional em relação
ao processo de boot e serviços a serem carregados, dentre outros;
c) gerenciamento do computador: autoriza lidar com itens do hardware
como particionamento de disco;
217
d) visualizador de eventos: permite acessar os logs do Windows e de aplica-

ções, importante para a gerência de segurança;
e) contas de usuário e segurança familiar: consente a criação, remoção de
contas e alteração delas, bem como, controle de acesso à internet (focado
em menores);
f) rede e internet: aglutina neste local o suporte à rede e compartilhamento
de recursos via rede;
g) aparência e personalização: permite personalizar a aparência e o funcio-
namento do Windows;
h) hardware e sons: dá licença ao ajuste de dados dos periféricos.
REGEDIT
O Windows mantém sua configuração em um banco de registros que pode ser

ajustado com o aplicativo regedit. Para utilizá-lo no prompt ou no menu iniciar,
mande executar regedit. Você obterá uma tela como a da figura a seguir, em que
notaremos a organização dos registros por classes.
Thiago Rocha (2012)
Figura 167 - Regedit do Windows 7: tela principal
Não descreveremos os itens do register pela extensão, mas você pode obter
um tutorial detalhado em <http://www.j79zlr.com/reg_tutorial.php> e em
<http://www.techsupportalert.com/pdf/e1209.pdf>.
Lembramos que, se fizermos alterações erradas no register, podemos ter pro-
blemas com a funcionalidade de parte ou de todo o Windows e de aplicações.
Logo, após quaisquer alterações e antes de salvá-las, devemos realizar um backup
que servirá como ponto de restauração.
Além das ferramentas nativas, existem diversos softwares no mercado que
complementam as funcionalidades de administração de uma estação Windows,
sendo alguns de licença livre e alguns comerciais.
Vamos discutir alguns.
218
AIDA64
AIDA64, da empresa Lalalys, consiste no atual e conhecido aplicativo Everest.

Esse software permite de forma simples e funcional levantar as características de
uma máquina. Para realizar o download, acesse o site <http://www.lavalys.com/>,
onde obtemos uma cópia de teste. No momento da escrita deste texto, tínhamos
a versão 2.20, usaremos a Extreme Edition de exemplo.
Após baixar a aplicação e instalar, teremos na sua execução algo como a figura
a seguir:
Thiago Rocha (2012)

Figura 168 - AIDA64
Essa ferramenta é importante por permitir uma visão clara e organizada de

nossa configuração de hardware, software e como está sendo usada.
SANDRA
Uma alternativa ao AIDA64 consiste na aplicação SANDRA (System ANalyser,

Diagnostic and Reporting Assistant) da SiSoftware, disponível em <http://www.
sisoftware.net>, que apresenta funções semelhantes ao AIDA64, mas com mais
facilidades de teste de hardware. Podemos ver na figura a seguir a tela inicial da
aplicação.
219
Thiago Rocha (2012)

Figura 169 - SiSoftware Sandra
CCLEANER
Uma tarefa normalmente chata de ser realizada é a limpeza de logs e arquivos

temporários, e também a verificação de inconsistências no register do Windows.
O aplicativo CCleaner desempenha essa tarefa muito bem. Ele pode ser obtido
em <http://www.piriform.com/ccleaner>.
Listamos, neste tópico, diversas ferramentas para o gerenciamento do Win-
dows e vimos que, além destas, podemos fazer uso de softwares disponíveis no
mercado.
3.7.2 FERRAMENTAS PARA ADMINISTRAÇÃO LINUX
Para cada tarefa, a ferramenta certa. O sistema operacional Linux constitui

uma solução com grande facilidade e flexibilidade em sua customização. Geren-
ciar esse recurso então será importante. O Linux apresenta diversas ferramentas
nativas e algumas podem ser instaladas para o auxílio na administração e no
gerenciamento.
FERRAMENTAS NATIVAS
Existem diversas distribuições Linux no mercado, cada uma opta por organizar
seu sistema de arquivo de uma forma. Um exemplo: algumas colocam os arquivos
de configuração no diretório /etc (padrão do Unix), outras em /usr/local/etc, /var/
etc e tantos outros lugares. Os arquivos de configuração estarão lá, mas você terá
de consultar a documentação para encontrá-los.
220
Em relação aos demais componentes, muda bastante também. Cada distribui-

ção tem sua forma de carregar programas no processo de boot, bem como um
conjunto ligeiramente diferente de aplicativos. Contudo, os elementos bases que
vêm com o Unix são mantidos em todas as distribuições.
Vamos aprender, neste tópico, as principais ferramentas nativas e algumas
que você instalar.
HARDWARE
O lspci e lsusb constituem excelentes ferramentas para listar a configuração do

hardware. O lspic (podemos usar com a opção –v) lista o barramento PCI identifi-
cando os componentes ligados a ele. O lsusb faz isso para o USB.
A figura a seguir mostra um exemplo, recortando alguns itens. Essa informa-
ção é muito útil para parametrizarmos nosso kernel linux.
root@aldeia:/home/garcia# lspci
(rev a1)
00:01.0 ISA bridge: nVidia Corporation MCP55 LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation MCP55 SMBus (rev a2)
(rev a2)
(rev a1)
(rev a2)
00:04.0 IDE interface: nVidia Corporation MCP55 IDE (rev a1)
Controller (rev a2)
Controller (rev a2)
Controller (rev a2)
… <recortado>
01:08.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22/A

IEEE-1394a-2000 Controller (PHY/Link)
06:00.0 VGA compatible controller: nVidia Corporation NV44
[GeForce 7100 GS] (rev a1)

root@aldeia:/home/garcia# lsusb
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Figura 170 - Execução de lspci e lsusb

221
O diretório /proc é um elemento importante na administração do Linux, pois

permite o acesso às estruturas de dados internas do kernel Linux mostrando da-
dos-chave sobre processador, memória e outros itens.
Entre em seu diretório /proc e tente um more cpuinfo. A figura seguinte mostra
uma saída em que identificamos informações-chave do processador em uso.
Se mais de uma CPU ou um núcleo existir, as informações de cada um serão
mostradas em sequência.
#processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 75

model name : AMD Athlon(tm) 64 X2 Dual Core Processor 4600+
stepping : 2
cpu MHz : 2399.997
cache size : 512 KB
Figura 171 - more /proc/cpuinfo
Existem diversos outros arquivos com conteúdos essenciais. Os diretórios nu-

méricos em /proc são associados aos processos em execução.
Se você desejar informações do processo, vá para o diretório e veja os dados.
O /proc é o que chamamos de pseudossistema de arquivo, já que a árvore de
arquivos e diretórios é mapeada em memória nas estruturas do sistema operacio-
nal e não em disco.
SHELLS
Diversas shells existem no mercado, em especial a bourne shell (sh), C shell

(csh) e korn Shell (ksh). Cada uma delas possui uma linguagem de programação
de scripts levemente diferente.
AWK
O Awk é o que chamamos de “canivete suíço” para manipulação de strings.

Você consegue fazer praticamente tudo que quiser com uma string. O Awk será
uma ferramenta essencial em seu trabalho.
Você poderá conhecer mais o utilitário awk ao acessar <http://www.awktuto-
rial.com/> e lendo sua main page (página oficial).
222
KDE e GNOME
Tanto o KDE como o Gnome são ferramentas gráficas de administração do sis-

tema, que podem ser usadas para obter simplicidade na execução dos processos.
A localização das ferramentas no KDE na aba system settings é mostrada na
figura a seguir.
Nela, você pode ver uma série de itens parecidos com o painel de controle do
Windows.
Thiago Rocha (2012)

Figura 172 - Setagem do sistema Linux no KDE
WEBMIN
O Webmin, disponível em <http://www.webmin.com>, consiste em uma fer-

ramenta de administração via rede para máquinas Linux (e outros Unix) escrita na
linguagem perl.
O aplicativo após a instalação permite a administração do sistema, empregan-
do um navegador de internet. Vamos apresentar rapidamente sua instalação:
a) realize o download do site assinalado anteriormente. Neste exemplo, vamos
optar pela versão tar.gz coloque o arquivo em /opt;
b) descomprima e desempacote com o gunzip e tar;
c) vá para o diretório criado e execute ./setup.sh, lembrando de anotar o
nome de usuário e senha.
Pronto, está instalado e você pode acessá-lo empregando o endereço IP e a
porta configurada, como na figura seguinte. Visite as diversas abas e veja toda a
funcionalidade do software. Note que se você não possui a biblioteca Perl SSleay,
não terá criptografia em sua sessão podendo ter problemas.
223
Thiago Rocha (2012)

Figura 173 - Webmin
Você aprendeu, neste tópico, que o Linux já traz diversas ferramentas adminis-
trativas instaladas e que podem mudar de distribuição para distribuição. Também
falamos das principais ferramentas e do Webmin.
3.8 GERECIAMENTO E MANUTENÇÃO
3.8.1 UPGRADE E MANUTENÇÃO NO AMBIENTE WINDOWS 7 E LINUX
Pense em uma casa que vive com lixo espalhado pelos cantos, objetos soltos.
Talvez não seja o local mais adequado para se encontrar algo, como uma carteira
de identidade que acabou de cair.
Pense num computador com o sistema operacional instalado e com os arqui-
vos sem qualquer organização, encontrar algo será difícil, usar esse ambiente
também. Temos, então, como tarefa manter a organização do sistema operacio-
nal e mantê-lo sempre atualizado.
Independentemente de lidarmos com Windows ou Linux, os procedimentos e
comportamentos são muito parecidos. Vamos discuti-los neste tópico.
A MANUTENÇÃO
Devemos usar a manutenção preventiva, e estarmos atentos a uma série de

itens em especial:
a) apagar arquivos temporários: nosso sistema operacional mantém uma
grande quantidade de arquivos temporários. No Linux, eles estão em /tmp.
No Windows, no diretório do Windows em Temp. Esses arquivos, após a apli-
cação ser fechada, apenas ocupam espaço. No caso do Windows, se mantém
224
arquivos temporários no perfil de cada usuário. O mesmo raciocínio vale para

os caches de navegadores e outros softwares, que após um tempo podem
ser descartados. No Windows, podemos usar o aplicativo Ccleaner (<http://
www.piriform.com/ccleaner)> para ajudar a apagar arquivos temporários;
b) logs: os registros de atividades, logs, são gerados tanto pelos softwares
aplicativos como pelo sistema operacional. Os logs devem ser lidos perio-
dicamente para garantirmos que nada esteja errado no sistema e que exija
manutenção. Depois da verificação, podemos comprimi-los e armazená-los
em uma mídia de backup;
c) instalação de novas aplicações: o Windows ou Linux são apenas a base
para se trabalhar, onde softwares que não estejam sendo usados devem ser
removidos por questão de segurança;
d) backup: consiste em um elemento de manutenção primordial onde temos
a garantia de segurança para nossas informações.
Diversos outros itens devem ser levados em consideração, tanto os softwares
como a manutenção do hardware. Em especial, devemos ter o processo de manu-
tenção como elemento de apoio, para se evitar falhas no sistema e para facilitar a
recuperação dele numa urgência.
UPGRADE
O upgrade significa atualizar para uma versão mais nova. Novas versões de
software surgem para prover duas facilidades em especial:
a) correção de falhas, o que pode significar correção de um erro que não per-
mite a aplicação cumprir o que devia ou uma correção de uma falha de se-
gurança;
b) implementar novas funcionalidades para o usuário.
Devemos estar atentos tanto às correções e atualizações que existam quanto
ao sistema operacional e demais aplicativos. De nada adiantará termos um siste-
ma operacional atualizado se seu servidor de banco de dados ou suas ferramen-
tas de Office Suite estão desatualizadas e com falhas.
O WINDOWS
O processo de upgrade do Windows se dá pela aplicação de patch de corre-

ção obtidos no site do desenvolvedor, Microsoft. Esse processo pode ser manu-
al, onde escolhemos cada pacote de correção, ou automático, onde deixamos o
Windows Update realizar a tarefa.
225
Um patch Windows consiste em uma grande coleção de correções para o sis-

tema operacional empacotadas para facilitar a vida do usuário e ele não cometer
erros, além de garantir a compatibilidade entres as várias correções.
Podemos agendar para que o Windows realize sozinho, o que, no entanto,
pode gerar problemas. Pense no Windows realizando o upgrade do sistema ope-
racional em um notebook e a bateria descarregar. Por essa e outras situações, é
mais adequado e seguro você mesmo executar o upgrade no momento em que
julgar adequado.
Descreveremos o processo para aplicação de correções via Windows Update.
Vá ao painel de controle e clique em Windows Update (figura a seguir). Nela,
vemos que existem atualizações disponíveis, neste caso, não criticas, se desejar,
clique na listagem de atualizações.
Thiago Rocha (2012)
Figura 174 - Windows Update
Ao clicar na listagem anterior, obteremos algo como a figura a seguir, em que

temos listadas as atualizações disponíveis e, na sua direita, uma breve introdução
do que se trata.
Se desejar a atualização, clique no box à esquerda e depois em ok na base da
tela e as atualizações serão instaladas.
Thiago Rocha (2012)
Figura 175 - Listagem de atualizações Windows
No caso dos aplicativos Windows, de tempos em tempos, devemos verificar se

existem atualizações disponíveis para eles no site do desenvolvedor.
Um cuidado importante é a criação de pontos de restauração no Windows
quando realizamos grandes mudanças nele.
226
LINUX
O Linux por ser um sistema operacional de código aberto que nos permite
realizar atualizações nele, baixando correções em seus diferentes aplicativos e
atualizar o kernel do sistema operacional com uma customização mais adequada
para nosso hardware.
Devemos estar atentos tanto a novas versões do kernel, como a novas versões
de aplicativos-chave no Linux como as bibliotecas, exemplo glibc e na parte de
servidores. Os demais cuidados são comuns ao Windows. Ter backup de tudo que
vamos substituir de forma tal que possamos voltar para a versão anterior do sof-
tware se for necessário.
Discutimos, neste tópico, que da mesma forma que uma casa bagunçada fica
difícil trabalhar, fica num sistema computacional, sendo essencial a manutenção
de nossos softwares, em especial do sistema operacional, permitindo a instalação
de correções e novas funções via upgrade.
3 ADMINISTRAÇÃO DE SISTEMAS OPERACIONAIS
227
Anotações:
MINICURRÍCULO Do AUTOR
Cláudio Martins Garcia possui graduação em Ciências da Computação pela Universidade Federal
de Goiás, mestrado em Ciência da Computação pela Universidade de Campinas (UNICAMP) na
área de Sistemas de Computação. Atualmente é professor da Pontifícia Universidade Católica de
Goiás (PUC - GOIAS) e SENAI - Departamento Regional de Goiás (EAD). Atua em especial na área
de Sistemas da Computação e Ciência da Informação, como foco em uso de tecnologias no pro-
cesso de comunicação de forma segura e imersiva.
Índice
A
Advanced netfilter configuration 171, 172
API 50, 62, 96, 110
Applet 110
B
Bootável 181
Boot loader 131, 132, 181, 182, 183
BSD Unix 117, 120, 126, 137, 138, 159, 172
C
Clusterização 133, 135
Compilar 119, 123, 135, 144, 145, 146, 147, 149, 150, 155, 156, 159, 163, 179, 180, 182, 183, 184
E
Escalonamento 30, 32, 33, 42, 69, 80, 84, 85, 87, 96, 110
Evocado 195, 197, 199
Executável 124, 135, 138, 149, 153, 154, 155, 179, 180, 182, 193, 194, 203
F
Fortran 28
G
GIT 137, 138
GLIBC 137, 138, 139, 146, 147, 226
GNU 137, 138, 139, 150, 181
GPL 137, 138, 150
H
Hashi 86, 87
I
Inode 151, 153
Instanciação 78, 80
I/O bound 40, 41, 42
IP virtual server support 171, 172
ISO 18, 19, 74
J
Journaling 127, 129
K
Kernel do sistema operacional 48, 49, 50, 53
L
Linkado 153, 155
M
Middleware 28, 38
Modularização 50, 51, 52, 53
O
Otimização 130, 132, 135, 137, 160
P
Parametrizar 155, 160, 173, 174
Partição 127, 128, 129, 147, 155, 175, 176, 177, 184
Polling 32
Premissas 203, 204
S
Scripts 133, 134, 135, 144, 184, 186, 187, 190, 191, 192, 197, 198, 199, 203, 221
Segregar 110
Semântica 70, 96, 104, 105
Setarmos 181, 182
Swapping 115, 117, 127, 131
T
Time slice 46, 47, 48, 80
W
Worm 110
SENAI – Departamento Nacional
Unidade de Educação Profissional e Tecnológica – UNIEP
Rolando Vargas Vallejos

Gerente Executivo
Felipe Esteves Morgado

Gerente Executivo Adjunto
Diana Neri
Coordenação Geral do Desenvolvimento dos Livros
SENAI – DEPARTAMENTO REGIONAL DE GOIÁS
Ariana Ramos Massensini

Coordenação do Desenvolvimento dos Cursos a Distância no Departamento Regional
Cláudio Martins Garcia

Elaboração
Cláudio Martins Garcia

Revisão Técnica
Wânia Pereira
Design Educacional
Bárbara da Silveira
Jaqueline Tartari
Revisão Ortográfica e Gramatical
FabriCO
Denis Pacher
Thiago Rocha
Victor Américo Cardoso
Ilustrações
Denis Pacher
Thiago Rocha
Tratamento de Imagens
Karina Silveira
Diagramação
i-Comunicação
Projeto Gráfico

SistemasOperacionais FINAL BAIXA

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SistemasOperacionais FINAL BAIXA

Enviado por

Direitos autorais:

Formatos disponíveis

Série TECNOLOGIA DA INFORMAÇÃO - hardware

Robson Braga de Andrade

DIRETORIA DE EDUCAÇÃO E TECNOLOGIA - DIRET

Rafael Esmeraldo Lucchesi Ramacciotti

SERVIÇO NACIONAL DE APRENDIZAGEM INDUSTRIAL – SENAI

Robson Braga de Andrade

SENAI – Departamento Nacional

Rafael Esmeraldo Lucchesi Ramacciotti

Gustavo Leal Sales Filho

© 2012. SENAI – Departamento Regional de Goiás

SENAI Departamento Nacional

SENAI Departamento Regional de Goiás

3 Conceitos de sistemas operacionais. 2.Arquitetura de sistemas

I. Autor. II. Título.

Serviço Nacional de Setor Bancário Norte • Quadra 1 • Bloco C • Edifício Roberto

Quadro 1 - Habilitação Profissional Técnica em Manutenção e Suporte em Informática........................15

Tabela 1 - Representação em diversas linguagens de uma atribuição...........................................................70

2 Conceitos de sistemas operacionais........................................................................................................................17

3 Administração de sistemas operacionais............................................................................................................ 115

Minicurrículo do autor................................................................................................................................................... 229

CARGA CARGA HORÁRIA

• Gerenciamento de Serviços de TI 80h

A gestão dos recursos de hardware cabe ao sistema operacional. O tipo de processador, a

2.1 INTRODUÇÃO A SISTEMAS OPERACIONAIS

Você já se perguntou de que forma elaboramos um planejamento? Como

Figura 1 - A Arte da Guerra

Retornemos ao século XX, após a revolução industrial, na revolução elétrica.

Figura 2 - Administração moderna

A famosa norma ISO19001, almejada por tantas empresas, ensina às institui-

Denis Pacher (2012)

Em que consiste um sistema operacional?

SISTEMAS OPERACIONAIS COMPUTACIONAIS

Denis Pacher (2012)

Os primeiros computadores consistiam basicamente em estruturas de combi-

permitisse a operação do sistema computacional. O programa monitor não é so-

2.1.2 SEPARAÇÃO DE HW/SW - ASSOCIAÇÃO COM MÁQUINA DE VON

Na área de computação, temos o hábito de, algumas vezes, estudar algum

Vamos retornar à década de 20, quando o matemático Alan Turing definiu o

Alan Turing (1912 a 1954) em 1975 foi considerado o

SAIBA Leia mais informações sobre a Teoria dos Grafos em <http://

Viajando para a década de 50, constataríamos que o computador eletrônico

O TRANSISTOR: A PORTA LÓGICA

O transistor permitiu a flexibilidade, por meio de semicondutores, de se confi-

Figura 8 - Transistor em diferentes configurações

Podemos pensar no transistor como uma porta elétrica. Colocamos eletrici-

Interessante, não é mesmo? Mas provavelmente você vai se perguntar: o que

Denis Pacher (2012)

Figura 9 - Exemplo de arranjo de transistores

O transistor 2 (dois) vai deixar passar eletricidade apenas se o 1 (um) estiver

Figura 10 - Porta NOR com transistores

Vamos utilizar os valores da lógica matemática como verdadeiro e falso (0 e 1)

INTRODUÇÃO A SISTEMAS OPERACIONAIS

Ao longo da década de 40, com possibilidade de “transformar” o computador

Denis Pacher (2012)

Figura 11 - Sistema computacional modelo

2.1.3 FUNÇÕES EXERCIDAS PELO SISTEMA OPERACIONAL

Você já se perguntou como o computador pode executar vários programas ao

Figura 12 - Modelo de computador

Os componentes básicos desta figura você já conhece, não é mesmo? Então,

Depois de um longo período da construção do hardware computacional, os

A NECESSIDADE DE GERÊNCIA DO HARDWARE

Suponha que a aplicação que desejamos executar é um sistema de folhas de

Digamos que uma impressora da época tivesse capacidade de imprimir 20 ca-

Gerente entrada Saída Gerente