View
110
Download
2
Category
Preview:
Citation preview
1
Infernohttp://
www.vitanuova.com/
Seminário de MAC 5755Sistemas Operacionais Distribuídos
Cleber Miranda Barbozacleberc@linux.ime.usp.br
2
Introdução
O que é o inferno? Sistema Operacional que fornece facilidades
para o desenvolvimento e a execução de: Serviços Distribuídos Aplicações de Rede
Desenvolvido por Lucent Technologies' Bell Labs
3
Alguns requisitos
Sistemas pequenos 1MB RAM
Sistemas médios 4MB RAM
Sistemas maiores 16MB RAM
4
Principais características
Portabilidade: Intel, SPARC, MIPS, PowerPC Design Distribuído Adaptabilidade Dinâmica Aplicações portáveis Utilizado das seguintes maneiras:
Sistema Operacional Nativo Hospedado dentro dos seguintes sistemas:
Windows Unix (Irix, Solaris, FreeBSD, Linux, AIX, HP/UX) Plan 9
5
Influência
Influência do sistema operacional Plan 9 (três princípios):
Recursos como arquivos
Espaço de nomes
Protocolo de comunicação padrão
6
Recursos como arquivos
Todo recurso é visto como um arquivo Não importa se é local ou remoto
Acesso a recursos através das operações: open, close, read, write
Principais vantagens Interface simples e bem definida Alta portabilidade Segurança
7
Recursos como arquivos (Cont.)
Interface de rede: /dev/tcp, /dev/udp, etc
Informações de processos: /prog
Sistema de janelas: /dev/draw
Informações: /dev/user, /dev/time, /dev/sysname, /dev/random
Cada diretório tipicamente contém dois arquivos: data ctl
8
Espaço de Nomes
Representação uniforme de recursos Cada conjunto de arquivos é visto como
uma estrutura hierárquica Espaços de nomes podem ser
Importados Exportados
Uso do protocolo Styx Transparência de localização
9
Espaço de Nomes (Cont.)
Principal vantagem Aplicações podem usar recursos de maneira
totalmente transparente Exemplo de uso: depuração remota de
programas Um depurador gráfico poderia ler
informações presentes em /prog Detalhe: /prog pode ser local ou remoto
No caso de depuração remota, importa-se o espaço de nomes /prog
Como importar espaços de nomes?
10
Espaço de Nomes (Cont.)
Importando espaço de nomes:
mount tcp!143.107.45.20 /n/remote/cameramount tcp!143.107.45.21 /n/remote/vcr
bind /n/remote/camera /homework/camerabind /n/remote/vcr /homework/vcr
E para exportar espaço de nomes?
11
Protocolo de Comunicação
Styx Protocolo para apresentação de recursos Variação do protocolo 9P desenvolvido para o
Plan 9 Idéia básica: codificar operações de arquivos em
mensagens para serem transmitidas via rede Transparência completa de recursos Usuários (desenvolvedores de aplicações) não
vêem o protocolo, mas apenas aquivos Acima e independente da camada de
comunicação (TCP/IP, ATM, PPP, etc)
12
Protocolo de Comunicação (Cont.)
É o Styx quem provê:
Visão hierárquica de recursos
Informações de acesso: permissões, tamanhos e datas de arquivos (recursos)
Semântica para leitura e escrita
13
Protocolo de Comunicação (Cont.)
Modelo OSI (Open System Interconnection):
7 Application 6 Presentation 5 Session <======= Styx 4 Transport 3 Network 2 Data link 1 Physical
14
Protocolo de Comunicação (Cont.)
Resolvendo nomes:
echo www.ime.usp.br > /net/dns
cat /net/dns
143.107.45.20
15
Protocolo de Comunicação (Cont.)
Estabelecendo uma conexão: Ler o conteúdo de /net/tcp/clone
Resultado: /net/tcp/43 Escreva a mensagem a seguir em
/net/tcp/43/ctl :connect 8080 143.107.45.20
Em seguida, a comunicação com www.ime.usp.br é feita através da leitura e escrita sobre o arquivo /net/tcp/43/data
16
Limbo
Limbo é a linguagem de programação para o Inferno
Sintaxe influenciada pelo C e Pascal Compilador do Limbo semelhante ao do
Java Código objeto gerado (bytecode -
aquivo .dis) é independente de máquina Interpretação do código por uma
Máquina Virtual (Dis) - Segredo da portabilidade das aplicações
17
Limbo (Cont.)
Programação modular Um programa limbo é composto por um
conjunto de módulos que cooperam para realizar uma tarefa
Um módulo consiste basicamente de duas partes:
Especificação das interfaces públicas (funções, constantes, tipos abstratos de dados, etc)
Código que implementa as interfaces Módulos são carregados dinamicamente (load)
Checagem de tipagem rígida em tempo de execução e compilação
Tipos de dados abstratos
18
Limbo (Cont.)
Alguns tipos dados presentes na linguagem: Byte unsigned (8-bits) int signed (32-bits) big signed (64-bits) real long float (64-bits) list,array String channel (para comunicação entre processos) adt (análogo ao struct presente em C) pick (análogo ao union presente em C) module
19
Limbo (Cont.)
hello.b)implement Hello;include "sys.m";sys: Sys;include "draw.m";Hello: module{
init: fn(ctxt: ref Draw->Context, argv: list of string);};init(ctxt: ref Draw->Context, argv: list of string) {
sys = load Sys Sys->PATH;sys->print("hello, world\n");
}
20
Dis
Dis é a Máquina Virtual (MV) do Inferno Desenvolvido também para compilação
on-the-fly (just-in-time) Uso dos bytecodes para produzir código
nativo O design da MV envolve:
Conjunto de instruções Sistema de módulos
21
Dis (Cont.)
Instruções seguem o modelo CISC (Complex Instruction Set Computer): OP src1, src2, dst Exemplo: c = a + b
add a, b, c Existência de instruções para
Alocar memória, carregar módulos, criar processos
Sincronização e comunicação entre processos
22
Dis – Gerenciamento de memória (Cont.) O gerenciamento de memória está ligado
ao conjunto de instruções da MV Uso de um coletor de lixo híbrido
Contagem de referências real-time sweeping (mark-and-sweep), três
passos: Para todo objeto no sistema, se ele tem uma marca,
ela é limpa Através das pilhas de execução, encontra-se os
objetos que estão sendo referenciados, marcando-os No passo final, percorre-se o heap linearmente,
removendo todos os objetos que não possuem a marca
23
Segurança
O Inferno provê segurança de: Comunicação Controle de recursos Integridade de Sistema
Existência do conceito de canais de comunicação entre processos Mensagens criptografadas Mecanismos que evitam mensagens
corrompidas
24
Segurança (Cont.) Os recursos são acessados somente por
chamadas de módulos que os provê Adição e remoção de recursos de um
espaço de nomes é controlada Presença de mecanismos de autenticação
Alguns algoritmos de criptografia presentes: SHA, MD4, MD5, Elgamal (assinaturas), RC4,
DES, Diffie-Hellman (chave pública) Criptografia das mensagens é transparente
para as aplicações
25
Inferno/Limbo vs. JavaOS/Java Limbo vs Java
Ambos possuem sintaxe influenciada pelo C Utilização de uma máquina virtual por ambos Java usa o conceito de objetos Limbo é um pouco mais simples, entretanto
provê alguns tipos de dados sofisticados, como o channel (comunicação), além de mecanismos para controle de concorrência, autenticação, segurança, etc
Biblioteca gráfica do Inferno (Tk) mais completa que o AWT
26
Inferno/Limbo vs. JavaOS/Java (Cont.) Máquina virtual
A arquitetura do inferno segue o modelo de transferência de memória (memory-to-memory)
As instruções do Dis são traduzidas para uma única instrução de máquina (CISC)
Já a JVM (Java Vitual Machine) usa a arquitetura de pilha
Utizando o exemplo c = a + b, teriamos:push a push b add store c
27
Visão geral da arquitetura
28
Ambiente gráfico
29
Exemplos de uso
30
Inferno - Hoje Hoje o inferno se encontra em sua 4.a
edição
Desenvolvimento em passos lentos Lista de discussão apresenta por volta de 30
mensagens por mês
Talvez se o código fosse aberto…
Há planos para realizar integração com o Java
31
Referências Vitua Nova. Inferno Overview, em:
<http://www.vitanuova.com/inferno/papers/bltj.html> Sean Dorward, Rob Pike, David Leo Presotto, Dennis M.
Ritchie, Howard Trickey, Phil Winterbottom. The Inferno Operating System, em:<http://www.vitanuova.com/inferno/papers/bltj.html>
Rob Pike, Dennis M. Ritchie. The Styx Architecture for Distributed Systems, em: <http://www.vitanuova.com/inferno/papers/styx.html>
Dennis M. Ritchie. The Limbo Programming Language, em: <http://www.vitanuova.com/inferno/papers/limbo.html>
Phil Winterbottom Rob Pike Bell Labs.The design of the Inferno virtual machine, em:<http://www.vitanuova.com/inferno/papers/hotchips.html>
Recommended