Desenvolvimento em C no Plan 9 From Bell Labs

Plan 9 From Bell Labs é um sistema operacional, fruto de pesquisa do mesmo grupo que criou o sistema operacional UNIX¹ e a linguagem C. O sistema emergiu no final dos anos 80, e pode ser visto como uma tentativa de evoluir os conceitos do UNIX, em uma era onde gráficos e rede passaram a ser utilizados mais ostensivamente.

Ainda que tivesse a promessa de modernização do UNIX, o Plan 9 foi originalmente desenvolvido em uma época onde a internet como conhecemos (com browsers e outras ferramentas, hoje utilizadas frequentemente no nosso dia-a-dia) ainda não era uma realidade. Portanto, o sistema não possui um browser capaz de atender às demandas modernas. Alguns forks do sistema (como o 9front, descrito nas próximas seções) possuem alguns browsers mais "recentes", porém sem a premissa de habilitar suporte completo à web contemporânea.

O sistema é descrito por seus criadores² como um "argumento" em prol de simplicidade e claridade, sendo um UNIX levado ao extremo. Dentre suas características marcantes, pode-se citar o Plan 9 como um sistema para a criação e o gerenciamento de um ambiente de computação distribuída, onde máquinas separadas atuam como terminais, ou servidores de CPU, e até mesmo servidores de arquivos. Desta forma, as máquinas conectadas funcionam como um cluster, e compartilham diversos recursos entre si.

Plan 9 From Bell Labs é, infelizmente, um sistema já abandonado pelos desenvolvedores originais. Suas reminescências são, hoje, muito bem-mantidas por uma comunidade de fãs em um conjunto de forks que, surpreendentemente, são hoje objetos de pesquisa para resolução de problemas modernos, sobretudo no que tange a design de sistemas operacionais.

O Plan 9 ainda possui alguns forks (ou distribuições) notórios em funcionamento. Como exemplo, temos:

• 9legacy, que visa manter o sistema "original", e apenas aceitar patches de compatibilidade;
• 9atom, que visa adicionar algumas arquiteturas extras para o kernel e suporte extra para hardware e alguns sistemas de arquivos;
• 9front, o fork utilizado para os testes do projeto descrito neste artigo, que visa aceitar patches ostensivos e abarcar uma comunidade de fãs, sendo o fork mais funcional para computadores modernos;
• Inferno, um sistema da empresa Vita Nuova, mantido como software livre, afim de promover uma linguagem de programação específica, para tentar simplificar e manter a segurança de aplicações: a linguagem Limbo;
• Harvey, um sistema operacional de 64-bit que visa trazer o Plan 9 para um universo que se adeque aos padrões ANSI e POSIX, e pode ser compilado utilizando compiladores modernos, como gcc ou clang³;
• Jehanne, um fork feito sob a premissa de dar continuidade ao princípio de simplicidade do Plan 9, e também de simplicidade no design de sistemas operacionais modernos. Distribuído como software livre, possui bastante atividade em seu blog, trazendo discussões interessantes para entusiastas de desenvolvimento de sistemas.

Plan 9 possui outros forks, mas estes são, provavelmente, os mais relevantes da atualidade.

Neste projeto, como apontado anteriormente, utilizei o 9front para testes, porque também tenho-o instalado em uma partição extra na minha máquina. A beleza de ter este tipo de sistema instalado é perceber a facilidade na localização de recursos do mesmo. Por ser algo tão "oldschool", encontrar material a respeito do seu uso e do seu funcionamento envolve ler os diversos artigos no diretório /sys/doc (todos os artigos distribuídos em PostScript, podendo ser compilados "na hora" e vistos no visualizador de documentos⁴). Para outras situações, basta utilizar as páginas de manual, as famosas manpages, que funcionam da exata mesma forma como no Linux⁵.

Adicionalmente, preciso ressaltar o quão interessante é a filosofia do sistema. Os compiladores são modulares e auto-contidos o suficiente, a ponto de tornar cross-compiling para diversas arquiteturas uma operação completamente trivial. Ou seja, se seu sistema estiver sendo executado para arquitetura x86, mas sua arquitetura for x86₆₄, você poderá recompilar o Plan 9 por completo (kernel + userland) em menos de cinco minutos. Compare este tempo ao tempo de compilação do kernel Linux, ainda que compilado com o mínimo de features possível. Mesmo assim, Plan 9 será compilado muito mais rapidamente, e isto proverá, imediatamente, um sistema completo e pronto para o funcionamento.

A maior parte do desenvolvimento foi feita em meu sistema Void Linux x86₆₄, sob o editor de texto Emacs; afinal, ninguém precisa de algum editor de texto especial para escrever código algum. Sinto-me confortável utilizando o Emacs para desenvolvimento, então fiquei seguro ao utilizá-lo.

Alguns dos testes foram feitos utilizando uma ferramenta chamada plan9port, que faz funcionar algumas (não todas) as ferramentas do Plan 9 no Linux. Em especial, o que utilizei foi o compilador 9c e o linker 9l (que na realidade são wrappers para compiladores próprios para Linux), e o terminal 9term por motivos estéticos.

Para scripts de compilação, utilizei a ferramenta mk do plan9port inicialmente, mas logo reverti para o make, quando precisei adaptar o sistema de build utilizando o mk para o Plan 9 de verdade. Maiores diferenças serão destacadas adiante.

Tenho o 9front instalado tanto de forma nativa quanto em um drive virtual, bootável via QEMU dentro do Void Linux⁶. Após o final do desenvolvimento usando plan9port no Linux, bastou trazer o código para o QEMU e, em seguida, para o 9front nativo, e o projeto funcionou com mudanças mínimas que não afetaram o build para Linux com plan9port. O restante do trabalho baseou-se apenas em adequar o arquivo mkfile para que funcionasse no 9front (mais sobre este arquivo será dito a seguir).

O projeto possui apenas três arquivos relevantes:

• 9mine.c
• mkfile
• Makefile

Onde 9mine.c é o arquivo de código em C, mkfile é o arquivo de configuração e build para Plan 9, e Makefile é o arquivo de build para o Linux.

Para compilar o projeto, foram utilizados tanto make (Linux/plan9port) quanto mk (Plan 9).

Na realidade, nenhum fork do Plan 9 possui um bom sistema de controle de versão. Há um script comunitário que funciona de forma similar ao git mas que, primariamente, não passa de um wrapper para o hget (similar ao wget)⁸.

Existe uma ferramenta comunitária de suporte para Mercurial, também lá chamada de hg, mas que não utilizei, por não ter usado Mercurial para controle de versão. Há rumores de que esta ferramenta "dá para o gasto", mas é insuficiente em muitos requisitos. Todavia, é a ferramenta primária relacionada a updates do sistema no 9front.

Ainda que esta descrição de sistemas de controle de versão para Plan 9 pareça absurda, lembre-se de que este é um sistema que predata a internet como a conhecemos, e com uma base de fãs que preferem o jeito "oldschool". Sendo assim, seria mais comum falar em patches na forma de diffs, vindos por e-mail, e que são incorporados aos arquivos utilizando uma ferramenta para tal. Um projeto de integração de controle de versão com o Plan 9 provavelmente valeria-se da ferramenta utilizada para isto. Portanto, fica bem claro que software de controle de versão no Plan 9 deveria ser preferencialmente não-monolítico.

Caso você esteja curioso com relação à forma como o sistema é, normalmente, "atualizado", o procedimento passa pela montagem de um diretório remoto, conectado aos servidores dos mantenedores do fork utilizado, através do protocolo 9p, que também é uma das características-estrela do Plan 9, na qual, infelizmente, não vou me aprofundar aqui⁹.

Como antes dito, um programa básico em C para o Plan 9 pode ser dramaticamente diferente do que vemos hoje para Windows, Linux e OS X. Abaixo, temos um "Hello, world!" bem simples.

#include <u.h>
#include <libc.h>

void
main(void)
{
    print("Hello, world!\n");
    exits(0);
}

Leitores acostumados com ANSI C poderão assustar um pouco com o exemplo. Como pode ser visto, apesar de estarmos imprimindo algo na tela, não há sequer uma sombra remota de stdio.h ou de printf, pois estas são funções que não existem no Plan 9¹⁰. Mas engana-se quem acha que não são suficientes: ao invés da implementação de um padrão enorme, o foco está em deixar as coisas o mais simples possível para o programador.

Os cabeçalhos u.h e libc.h são cabeçalhos padrões no Plan 9, e já englobam uma quantidade enorme de coisas específicas. Deve-se incluir estes cabeçalhos nesta exata ordem para evitar problemas de linking.

A função print(3)¹¹ funciona da exata mesma maneira que printf, porém com algumas diferenças: Plan 9 suporta unicode out-of-the-box, então há flags para o tipo Rune, por exemplo, que simboliza um caractere UTF-8.

exits(3)¹² é a função comum para encerramento de um processo qualquer, recebendo, como parâmetro, uma constante de caracteres (de tamanho máximo ERRLEN), especificando brevemente o motivo para a saída do processo. Veja, porém, que, ao contrário de sistemas Unix-like convencionais, a função de ponto de entrada (main) não possui valor de retorno. Portanto, o uso de exits(3) é opcional, no caso apresentado. Também, passar um ponteiro nulo para esta função (no caso, o valor 0 ou o macro nil) indica que o processo foi terminado normalmente.

Plan 9 não possui um equivalente direto a scanf(3)¹³. Ao invés disso, entrada a partir do console é uma atividade delegada à biblioteca libbio. Enquanto isto parece algo não-usual, é uma prática que compactua com a filosofia do sistema, que envolve levar a filosofia UNIX ao extremo: se tudo é um arquivo, e arquivos são lidos como streams, então a entrada do console também poderá ser tratada como um stream¹⁴.

Ademais, libbio trata entrada e saída para arquivos no formato de um buffer, alocado na estrutura Biobuf. Basta abrir o buffer para leitura com stdin:

#include <u.h>
#include <libc.h>
#include <bio.h> /* Cabeçalho da libbio */


/* No ponto de entrada da aplicação */
void
main(void)
{
    /* Estrutura do buffer */
    Biobuf bstdin;

    /* Abertura do buffer. O argumento '0' indica stdin */
    if(Binit(&bstdin, 0, OREAD) == Beof) {
        fprint(2, "Erro ao conectar stdin a bio: %r");
        exits("Binit");
    }

    /* Lendo uma linha a partir de stdin */
    char *str;
    int   len;

    str = Brdline(&bstdin, 10); /* 10 = \n */
    len = Blinelen(&bstdin);

    /* remove o caractere de fim-de-linha na string */
    if(str) {
        str[--len] = '\0';
    }

    print("Lida a frase \"%s\" de tamanho %d\n", str, len);

    /* Fechamento do buffer */
    Bterm(&bstdin);
    exits(0);
}

Normalmente, quando escrevemos uma aplicação em C/C++, sabemos que podemos utilizar argc e argv, passáveis como parâmetro para main, para recuperar os argumentos passados via console para nossa aplicação. No Plan 9, isto não é diferente.

Como meu jogo tinha um modo debug, eu precisava de uma flag -d que pudesse ser passada via console. Assim, minha primeira aproximação para este problema foi a forma mais ingênua:

void
main(int argc, char **argv)
{
    int i;
    int debug = 0;
    for(i = 1; i < argc; i++) {
        if(!strcmp(argv[i], "-d")) {
            debug = 1;
            break;
        }
    }

    if(debug) {
        print("Got a debug flag!\n");
    }

    exits(0);
}

Todavia, o Plan 9 já tem algo para te ajudar com isso, na forma de macros! Como muito bem apontado pelo Ricardo Lanziano, existe uma forma muito mais simples de lidar com este problema. Deixo a interpretação para o leitor:

void
main(int argc, char **argv)
{
    int debug = 0;

    ARGBEGIN {
        case 'd':
            debug = 1;
            break;
    } ARGEND;

    if(debug) {
        print("Got a debug flag!\n");
    }

    exits(0);
}

O arquivo mkfile não é particularmente complicado ou muito diferente de um arquivo Makefile como conhecemos; porém, seu design foi feito sob uma premissa de maior integração com o sistema operacional, o que ocasiona alguns pequenos truques pré-preparados e muito interessantes¹⁶.

Abaixo, coloco uma cópia direta do arquivo mkfile do 9mine, cuja ação descreverei a seguir.

</$objtype/mkfile

BIN=/$objtype/bin/games

9mine:  9mine.$O
        $LD -o $target $prereq

install: 9mine
         mv 9mine $BIN

%.$O:    %.c
$CC $CFLAGS $stem.c

Este script é necessariamente independente de arquitetura, porque "herda" o conteúdo do arquivo /$objtype/mkfile, que é suprido pelo sistema. $objtype é uma variável de ambiente que especifica a arquitetura nativa para a qual pretende-se compilar a aplicação. Como o sistema estava sendo executado para uma arquitetura 386, o simples ato de invocar mk no diretório cria um arquivo 9mine.8, similar a um arquivo .o no Linux. Este arquivo, então, será linkado e transformado no binário de nome 9mine.

O interessante deste método é que, como ele depende de uma variável de ambiente, o mero ato de modificá-la já habilita suporte a compilação cross-platform. Plan 9 tem compiladores de C extremamente compactos e que funcionam para diversas arquiteturas, o que torna esta uma operação fácil¹⁷.

Por exemplo, suponhamos que estamos compilando uma aplicação em C para ser executada em um Raspberry Pi 2 ou 3. A arquitetura destes dispositivos é ARM; além disso, é possível compilar o sistema Plan 9 para ARM¹⁸. Dito isto, a partir do seu computador pessoal de qualquer arquitetura, que esteja executando o Plan 9, é possível produzir um binário compatível com a arquitetura ARM, utilizando o seguinte comando:

objtype=arm mk

Isto fará override da variável $objtype para o próximo comando, que é mk, e utilizará variáveis e compiladores apropriados para a arquitetura-alvo. Sendo assim, o script criará um objeto sob o nome 9mine.5, onde o número após o ponto diz respeito à arquitetura-alvo¹⁹.