Inferno http://www.vitanuova.com/

1. Infernohttp://www.vitanuova.com/ Seminário de MAC 5755 Sistemas Operacionais Distribuídos Cleber Miranda Barboza cleberc@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/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?

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>