Inferno Overview, em - Rede Linux IME-USP

Inferno
http://www.vitanuova.com/
Seminário de MAC 5755
Sistemas Operacionais Distribuídos
Cleber Miranda Barboza
[email protected]
1
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
2
Alguns requisitos

Sistemas pequenos


Sistemas médios


1MB RAM
4MB RAM
Sistemas maiores

16MB RAM
3
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
4
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
5
Recursos como arquivos

Todo recurso é visto como um arquivo


Acesso a recursos através das operações:


Não importa se é local ou remoto
open, close, read, write
Principais vantagens



Interface simples e bem definida
Alta portabilidade
Segurança
6
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
7
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
8
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?
9
Espaço de Nomes (Cont.)

Importando espaço de nomes:
mount tcp!143.107.45.20 /n/remote/camera
mount tcp!143.107.45.21 /n/remote/vcr
bind /n/remote/camera /homework/camera
bind /n/remote/vcr /homework/vcr

E para exportar espaço de nomes?
10
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)
11
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
12
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
13
Protocolo de Comunicação (Cont.)

Resolvendo nomes:
echo www.ime.usp.br > /net/dns
cat /net/dns
143.107.45.20
14
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
15
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
16
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
17
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
18
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");
}
19
Dis


Dis é a Máquina Virtual (MV) do Inferno
Desenvolvido também para compilação onthe-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
20
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
21
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
22
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
23
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


Alguns algoritmos de criptografia presentes:


Presença de mecanismos de autenticação
SHA, MD4, MD5, Elgamal (assinaturas), RC4, DES,
Diffie-Hellman (chave pública)
Criptografia das mensagens é transparente
para as aplicações
24
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
25
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
26
Visão geral da arquitetura
27
Ambiente gráfico
28
Exemplos de uso
29
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
30
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>
31