Inferno http://www.vitanuova.com/ by 2Y3w2q

VIEWS: 12 PAGES: 31

									         Inferno
http://www.vitanuova.com/

         Seminário de MAC 5755
   Sistemas Operacionais Distribuídos

        Cleber Miranda Barboza
        cleberc@linux.ime.usp.br


                                        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
       1MB RAM


   Sistemas médios
       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
       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


                                               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 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



                                                        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
       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
                                                    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

								
To top