Papo sobre kernel

Entre os meses de setembro e outubro, o diretor executivo da Revista do Linux, Rodrigo Stulzer, e o diretor técnico da Conectiva, Arnaldo Carvalho de Melo (mais conhecido no mundo Linux como ACME), trocaram alguns e-mails sobre o andamento do trabalho em torno da próxima versão do kernel do Linux. Papo vem, papo vai, a conversa ficou interessante. A Revista do Linux adaptou para os seus leitores os principais trechos da conversa e divulga, com exclusividade, algumas curiosidades sobre os desenvolvedores do kernel, como é o processo de desenvolvimento e o que virá de novo nas próximas versões. Assim, você fica por dentro do que acontece nos bastidores do desenvolvimento do sistema operacional do pingüim.

Rodrigo Stulzer - Afinal de contas, qual será a próxima versão? 2.6 ou 3.0?
Arnaldo Carvalho - 2.6, 3.0, ninguém ainda sabe qual será o próximo número. O que sei: 31 de outubro (Halloween), feature freeze, quando novos recursos não podem ser adicionados, depois disto, uns quatro a seis meses de estabilização, sendo otimista-realista (sendo pessimista = 1 ano).

Stulzer - Nossa! Seis meses de estabilização! E o pessoal consegue estar em estado de feature freeze e não incluir coisas novas? Eu tenho a percepção (de longe) que isso nunca ocorreu. E um ano em feature freeze não quer dizer que suporte a novos hardwares deixe de ser adicionado, certo?
ACME - Não. Há que se definir feature freeze: o core: VM, block layer, VFS, principais sistemas de arquivo (ext2, ext3), principais drivers (mais usados) entram em feature freeze. Mas, por exemplo, se eu terminar o NetBEUI, que é uma pilha de rede (algo grande) ela deverá ser aceita, já que não toca o core. Drivers novos também são aceitos, normalmente depois de passar um tempo em uma árvore como a do Alan.

Stulzer - Mas independente de qualquer coisa, um ano é muito tempo, pelo menos me parece. Ou isso faz parte do caminho de maturidade do kernel? Se conseguirmos em um ano será um avanço! Nos anteriores demorou bem mais.
ACME - Esta é uma das razões para que eu esteja ficando madrugadas adentro; sou responsável por Appletalk, X.25, IPX, LLC, algumas tarefas pendentes no TCP/IP (relacionadas a preemption), etc.

Stulzer - Mas você está fazendo tudo sozinho ou coordenando a maioria das coisas?
ACME - Sozinho, o Jay até me ajudava no LLC, mas, hoje em dia, não mais. Algumas pessoas relatam problemas e, melhor, casos de sucesso, como um funcionário da Cisco, que está usando o LLC para acessar controladores industriais. Segundo ele, é “non work related”, ou seja, não é algo que esteja fazendo para a Cisco.

Stulzer - Mas há sinais de que podemos ser otimistas quanto à data da próxima versão?
ACME - Sim, mas muita coisa que foi feita no 2.5 foi transportada para o 2.4, e é este o modelo que o Alan defende: vai se desenvolvendo na série “instável” e o que for sendo aprovado é transportado para a série “estável”; quando um número suficiente de mudanças da série “instável” estiver na série “estável”, muda o número da série “estável”.

Stulzer - Quem trabalha mais ativamente no desenvolvimento do kernel? Você se lembra de cabeça o que cada desenvolvedor faz? Vi que você já falou alguma coisa deles, mas tem pessoas que não foram citadas...
ACME - Veja o ranking abaixo:

Posição/Patches	Nickname	Descrição
1 - 682	torvalds	Conheço pessoalmente; como todos sabem, é finlandês. O apelido é Pinhead...
2 - 491	davem	Network demi-god, conheço pessoalmente; é norte-americano e trabalha na Red Hat. É com quem tenho maior contato, e já me envia piadas :)
3 - 490	kai	Mantenedor do ISDN, mas o grande número de patches está associado ao kbuild, o sistema de compilação do kernel. É estudante e mora na Alemanha. Não conheço pessoalmente, só pelo IRC.
4 - 346	viro	É russo e toma dois litros de vodka pela manhã. Fora isto, é o demi-god de sistemas de arquivos e do VFS (o que abstrai os sistemas de arquivos) e caçador de race conditions. Conheço pessoalmente e já file muitos cigarros dele. Trabalha para a Red Hat, mas se recusa terminantemente a usar um e-mail @redhat.com e usa Debian.
5 - 339	anton	Anton Blanchard trabalha na IBM. Creio que é canadense, conheço pessoalmente. É mantenedor do porte para PPC64 e grande colaborador do porte para Sparc.
6 - 319	akpm	Andrew Morton. Bom em tudo, velhão, ex-Nortel, era gerente, encheu o saco, largou tudo, mudou-se para a California (morava na Austrália, sua terra natal) para trabalhar com Linux, programando.
7 - 309	greg	Excelente pessoa, USB, hot-plug, LSM (Linux Security Modules). Norte-americano. Conheço pessoalmente, trabalha na IBM.
8 - 274	davej	Quase veio trabalhar na Conectiva, mas acabou decidindo trabalhar para a SuSE. Possivelmente, será o mantenedor do 2.6 (ou 3.0), mas creio que o Marcelo continuará e o Dave só irá ajudar na migração, já que mantém árvore com objetivo de reunir o que foi corrigido no 2.4, e ainda não no 2.5, i.e., Forward Port. É galês.
9 - 203	rmk	Russell King, inglês, independente, mantenedor do porte para a plataforma ARM e atual mantenedor do susbsistema serial do Linux, novidade no 2.5.
10 - 176	jgarzik	É norte-americano e trabalha na Mandrake, seleciona patches para drivers de rede, e é ~Sfirewall para patches~T para o Linus.Está recentemente tomando conta do merge de i2c. É mais conhecido por ser o mantenedor do driver para as placas de rede RealTek 8139.
11 - 159	davidm	David Mosberger-Tang, mantenedor do porte para IA64, funcionário da HP. Nunca conversei diretamente com ele, mas creio que lhe mandei um patch ou dois.
12 - 157	mochel	Patrick Mochel, OSDL, norte americano, já trabalhou na Transmeta, responsável pelo DeviceFS, outra novidade do 2.5
13 - 150	neilb	Um dos responsáveis pelo NFS, outra das novidades do 2.5, que terá direct io,ncp over tcp, nfsv4, etc.
14 - 148	axboe	Jens Axboe, dinamarquês, trabalha na SuSE e é responsável por uma das maiores novidades do 2.5, o Block I/O rewrite, que finalmente matará it buffer it heads, substituindo-a por Block I/O, que é uma abstração para transporte de unidades de I/O dentro do kernel.
15 - 130	rusty	Paul 'Rusty' Russel, australiano, trabalha na IBM, palhação, mexe com muita coisa, mas ficou conhecido por ser o arquiteto e principal implementador do ipchains (e subsistema no kernel associado a isto) e netfilter.
16 - 127	dalecki	Marcin Dalecki, maluco de pedra. Como é necessário para ser mantenedor do IDE/ATA, mas já foi queimado, o André Hedrick voltou à cena com Alan como firewall para o Linus. Polonês, trabalha como analista financeiro/ técnico para uma empresa de Venture Capital.
17 - 125	paulus	Paul Mackerras, velhão, australiano, trabalha na IBM, mantenedor do porte para PPC32, mantenedor do PPP, etc., conheço pessoalmente.
18 - 122	mingo	Ingo Molnar, húngaro, vive lá mesmo, trabalha na Red Hat e cuida dos servidores web tux e tux2, além de O(1) scheduler, NPTL e outro mundo de coisas. Nunca me encontrei com ele, nunca ouvi falar que tenha ido a alguma conferência de Linux.
19 - 110	vojtech	Tcheco, trabalha na SuSE, cuida da input layer, outra novidade do 2.5. Conheço pessoalmente.
20 - 98	jsimmons	James Simmons, se me lembro corretamente, é australiano, cuida de frame buffers. Nunca me encontrei com ele.
21 - 98	david-b	Trabalha com USB, não o conheço.
22 - 96	hch	Cristopher Hellwig é alemão, ex-Caldera, never-SuSE, atualmente contratado pela SGI para fazer o merge do XFS no 2.5, o que já foi feito. Contribuiu muito também com o JFS e muitas outras coisas. Tem 19 anos e um cabelo duro espetado, verde. É gente boa, conheço pessoalmente.
23 - 91	aia-21	Anton Altaparkamov. Creio ser búlgaro, estuda no UK, NTFS NG, suporte total a NTFS, outra novidade (bastante esperada) do 2.5
24 - 90	acme	Eu mesmo...
25 - 78	agrover	Inhell, cuida de ACPI. Já me encontrei com ele, mas não conversamos.

Note que o número de patches não é equivalente ao valor da contribuição total. 405 pessoas têm seu nome nesta lista, o que não representa todas as pessoas que contribuiram, pois muita coisa foi feita antes do Linus começar a usar o BitKeeper, e muitos patches acabam indo via outras pessoas, como é o caso com boa parte dos 274 patches atribuidos acima ao davej (SuSE) e ao jgarzik (Mandrake). O Marcelo, por exemplo, não tem nenhuma entrada, efeito direto da carga que está tendo com a manutenção do 2.4. De todos acima, o mingo (Ingo Molnar, Red Hat) e akpm (Andrew Morton, digeo) são os que merecem boa parte do crédito por quão bom o 2.6 (ou 3.0) venha a ser.

Stulzer - Hmm, mas você enviou para ele? Como funciona este processo?
ACME - acme: bk push master.kernel.org:/home/acme/BK/llc-2.5 acme: envia e-mail para o davem com o patch e o endereço BK acima, pede para que faça o pull ou que comente ([RFC] bla, bla)
davem: bk pull master.kernel.org:/home/acme/BK/llc-2.5 davem: repete pulls de várias pessoas no que for relacionado a sua área de responsabilidade (Sparc64, PCI DMA, networking em geral)
davem: envia e-mail para o linus pedindo que execute bk pull master.kernel.org:/home/davem/BK/net-2.5
linus: bk pull master.kernel.org:/home/davem/BK/net-2.5
linus: libera nova versão
As árvores bk acima são exemplos, tenho árvores para x25, tcp/ip, janitoring, etc.

Stulzer - E o bitkeeper melhorou o que, afinal, a organização geral?
ACME - Temos controle de versões, sabemos quem fez o que, temos logs mais extensos, podemos retirar changesets suspeitos para ver se foi o causador de instabilidade, temos acesso mais rápido à árvore do Linus, antes da liberação para o povão, etc. Note que o número de patches não é equivalente ao valor da contribuição total.

Stulzer - Mas, pelo menos, isso mostra se as pessoas estão ativas ou não.
ACME - Mas pessoas como o Alexey, por exemplo, nem aparecem no radar acima, mas é quem dá a última palavra em rede quando o assunto é polêmico e contribuiu muito no passado em reescritas do core de rede, etc. Não anuncia o que está fazendo publicamente, mas o davem me disse que os dois estão trabalhando numa implementação de IPSEC para ser incorporada no mainline, coisa que nunca ocorrerá com o FreeSWAN.

Stulzer - Falando do 2.6 ou 3.0, o que está gerando um número maior de mudanças? Quais são as novas características que estão sendo incluídas no kernel e o que isso influencia no uso do Linux?
ACME - Dei uma palestra sobre isto no Peru. Filmaram, vou pedir uma cópia : Bem... NTFS completo, preempção kernel level (som, desktop com melhor responsividade, i.e. menor latência), NPTL (opa, os malucos do java com seus quilos de threads estão contentes, bem como a Oracle) BIO melhora no high end, VM melhorado. Hey, can you say R M A P?. O akpm está como gerentão, mas a implementação inicial foi do Rik. Ih, tem um monte de outras coisas...