1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
|
# Diferenças técnicas entre o Plan 9 e UNIX
Eu venho estudado o kernel do Plan 9 e comparando com as implementações de UNIX
que temos hoje, e muitas das coisas que eu comento pela internet sobre o Plan 9
são mal interpretadas ou rotuladas como "lentas" ou contraditórias e que
precisam funcionar por outro caminho. Eu fui a fundo entender essa diferença de
comunicação que estamos tendo e pretendo remover esses mal-entendidos com esse
post.
## "Plan 9 tem comunicação baseada em arquivo e, portanto, é lento"
Apesar dos syscalls de arquivo serem semelhantes, o comportamento desses
syscalls divergem bastante conforme a complexidade aumenta.
Se você estiver operando um arquivo, tanto o Plan 9 quanto o UNIX vão triggar
uma mudança de privilégio, que então o número do file descriptor é usado pra
selecionar uma entry de um lista de virtual table que contém as operações
corretas para o driver que lida com o arquivo aberto. Até aqui, não há trocas
de contexto e os dois operam mais ou menos na mesma forma.
A diferença é que o UNIX abandonou completamente a ideia de tudo ser um arquivo
e, como o Rob Pike disse uma vez: "é tudo um arquivo, mas alguns arquivos são
mais iguais que outros". Se você quiser desenhar algo na tela de um UNIX, você
não faz um `write(2)` para o kernel, você é obrigado a se comunicar via IPC ou
tornar o processo mais acoplado com o *driver* do sistema operacional através
de shared memory.
O Plan 9, por outro lado, leva isso até as ultimas consequências e de forma
mais enxuta. Os drivers dos file descriptors ficam mapeados no processo, o que
reduz a quantidade de trocas de contexto, e o driver lida diretamente com o
buffer passado pelo programa. Um exemplo mais voltado para o gráfico como
citado anteriormente, o driver `draw(3)` fica mapeado junto com o kernel, que
então lida diretamente com os comandos enviados pelo programa, que realiza as
operações e devolve o programa para o modo de usuário, sem realizar uma troca
de contexto.
Vale ressaltar que sim, operações de I/O no Plan 9 podem causar uma troca de
contexto a depender do driver, então operações em rede ou sistemas de arquivo
montados em 9p ou usando o `pipe(3)` geralmente triggam uma troca de contexto.
A diferença é que o Plan 9 simplificou a operação e tornou I/O mais leve.
[Esse documento](https://ondoc.logand.com/d/5736/pdf) descreve melhor as
decisões de arquitetura do Plan 9, com as vantagens e desvantagens.
## "Plan 9 é confuso"
O Plan 9 é confuso porque ainda temos a mentalidade de como um computador
funciona pelo UNIX.
O Plan 9 separa o sistema operacional em 3 grandes "servers": CPU server, File
server e Auth server; e esses 3 têm suas configurações feitas de forma isolada,
então toda instalação de um Plan 9 "standalone" é uma composição de 3 ambientes
diferentes, que significa que são 3 configurações diferentes no mesmo sistema.
Ou então você pode fazer 3 configurações em 3 sistemas diferentes (inclusive
sendo sistemas operacionais diferentes), que foi para o quê o Plan 9 foi feito.
E também muitas das coisas que temos por garantido dos UNIXes modernos são
feitas de forma diferente, e como eu costumo dizer no IRC da bolha dev, o Plan 9
tem uma tendência a transformar código em infraestrutura. Um exemplo que eu
posso dar é sobre o `audio/mixfs` do 9front, que é o equivalente ao `pulseaudio`
ou `pipewire` do linux.
O audio do Plan 9 funciona ao escrever e ler no `/dev/audio` do sistema, como
nos antigos UNIXes, e esse `/dev/audio` é oferecido pelo dispositivo de sistema
chamado `#A`, e como nos antigos UNIXes ele tem o problema de só um poder usar
ele, etc. O `audio/mixfs` oferece um file system por 9p que tem a mesma
estrutura do `#A`, que então é bindado no `/dev` do namespace e então todo
software desse namespace vai rodar através do contexto do mixer e não no
contexto do kernel, permitindo mixagem de audio.
Com esse exemplo, fica claro como que as coisas acabam funcionando no Plan 9:
é tudo sobre uma composição de namespaces, você monta o ambiente adequado que você
quer que o processo rode e então roda o processo.
## "Plan 9 é inseguro"
De fato o Plan 9 tem algumas coisas que estão atrasadas pois se trata de um
sistema operacional de pesquisa de 3 décadas atrás, então você não vai
encontrar criptografias mais recentes, como o ed25519, e também VPNs do mercado
como o wireguard ou openvpn. Porém o modelo de segurança do Plan 9 não é
baseado em modelo de segurança ativa, como um firewall, mas de forma mais
passiva, "se um software não precisa ou não pode ver tais coisas, ele
simplesmente não vê isso". Isso dá através de namespaces e, no caso do 9front,
também por mecanismos parecidos com o `pledge(2)` do OpenBSD em nível de
namespace, o `chdev(1)` e comunicações com o `#c/drivers`.
## Conclusão
Com isso, eu acredito que algumas coisas fiquem mais claras. O Plan 9 tem um
modelo de arquivo, mas a implementação desse modelo é mais enxuta e simples,
permitindo uma maior performance, segurança e flexibilidade. No máximo, o Plan
9 é um sistema operacional de uso geral mas incompleto e com umas falhas devido
ao tempo que foi deixado de lado, o que é triste mas interessante para explorar
devido a sua codebase ser menor e mais simples, pode-se considerar como um
grande uncharted territory assim como vários outros modelos que foram deixado
de lados com o passar do tempo.
|
