1 / 31

Inferno http://www.vitanuova.com/

Inferno http://www.vitanuova.com/. Seminário de MAC 5755 Sistemas Operacionais Distribuídos Cleber Miranda Barboza cleberc@linux.ime.usp . br. Introdução. O que é o inferno? Sistema Operacional que fornece facilidades para o desenvolvimento e a execução de: Serviços Distribuídos

matilde
Download Presentation

Inferno http://www.vitanuova.com/

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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>

More Related