Amante do Kernel

Marcelo Wormsbecker Tosatti é Curitibano, tem 18 anos, e há três se interessa pelo desenvolvimento do kernel do Linux. Começou a lidar com informática aos 11 anos, em um computador de seu irmão com DOS. Logo depois ~Spenou~T durante dois meses para instalar uma distribuição da época, a Linux FT, e a partir daí começou a se interessar por programação. Atualmente trabalhando na Conectiva, Marcelo foi indicado, em um raro momento de unanimidade entre Linus Torvalds e Alan Cox, como novo mantenedor da série estável (2.4) do kernel do Linux, enquanto Linus e Alan se dedicam ao desenvolvimento da série 2.5. Em meio a entrevistas, telefonemas e seções de fotos, conseguimos um tempinho para um bate-papo com Marcelo, que nos conta como começou a colaborar no desenvolvimento do kernel e quais seus planos para a série 2.4, além de dar algumas dicas aos iniciantes. Confira o resultado.

RdL: Vamos começar devagar: qual foi a sua primeira contribuição para o Kernel?

MT: O primeiro patch a gente nunca esquece <risos>. Havia uma falha de segurança no suporte a IPV4, que poderia ser usada para gerar um ataque DoS (Denial of Service). Corrigi a falha, e enviei o patch que, embora funcionasse, não era o “jeito certo” de resolver o problema. Então recebi um e-mail do Alan (Cox) dizendo: “Olha, o jeito certo de se resolver o problema é este, e um outro desenvolvedor já corrigiu a falha”. Ou seja, meu primeiro patch nem foi aceito! <risos>.

RdL: Atualmente, quais partes do kernel você considera as mais interessantes?

MT: O sistema de memória virtual, sistemas de arquivos a parte de Block Layer, que ainda tem muito por fazer...

RdL: O que é a parte de Block Layer?

MT: É a parte de I/O, o controle de I/O para dispositivos de bloco, como dispositivos IDE e SCSI. Ela fica bem “junto” aos drivers.

RdL: E a VM (Memória Virtual)?

MT: A VM é tão complexa, tão “chata”, que eu acabo me interessando por ela. O nível de abstração em relação ao resto é muito grande, tem coisas que você tenta, tenta, e tenta fazer e nunca dão certo.

RdL: Com essa mudança meio “radical” que ocorreu recentemente, com o Linus aceitando a implementação da VM do Andrea Arcangeli em vez da versão feita pelo Rik Van Riel, como vai ficar esta parte no kernel 2.4 e no 2.5?

MT: No kernel 2.4 eu quero continuar com a implementação do Andrea, porque é simples, fácil de entender e não tem muito o que “inventar” em cima dela. Está funcionando, então não tem porque mexer. Tem alguns bugs pra consertar, claro, mas não dá pra reescrever toda a VM a esta hora.

RdL: A VM do Andrea é baseada na VM do Rik? Ou ele refez tudo do zero, ou implementou de forma diferente a mesma idéia?

MT: Não, já existe um código base, e você não precisa reescrever tudo pra mudar o sistema. O que está sendo mudado é a parte de “gerenciamento”, quais páginas de memória alocar, quais liberar, etc. Existe uma base pronta desde o início do Linux, e você só precisa mudar partes dela.

RdL: Você não acha que tem algo estranho em toda essa história? A VM do Rik vem sendo desenvolvida e testada desde a série 2.3 do kernel. E de repente, em um fim de semana, o Andrea senta e escreve um patch que se torna a “salvação da lavoura”?

MT: Não é que ela virou a salvação da lavoura. É que o Linus ficou de “saco cheio”. A VM estava sendo desenvolvida há tanto tempo, e tinha ficado tão complexa, que ele achou que não ia dar certo. Creio que foi uma decisão prematura dele. Olhe o tanto de problemas que tivemos com o kernel 2.4, simplesmente porque ele mudou a VM no meio de uma série estável. Se tivéssemos ficado com a VM do Rik, poderíamos ter consertado os problemas.

RdL: Supomos que o Alan Cox também vai te ajudar?

MT: Com certeza o Alan vai me ajudar. Provavelmente como uma espécie de “mentor”.

RdL: E como funciona a manutenção de um kernel estável? O processo de backport de um patch, etc?

MT: É difícil deixar o kernel “estável”. Sempre há bugs, e quando você arruma um aqui outro aparece em algum canto. Eu quero deixar a série 2.4 o mais estável possível, principalmente através da execução de testes no kernel antes de lançar uma nova versão. O pessoal da RedHat e da Conectiva vai ajudar, com um sistema automático de testes chamado Cerberus. Quero que todas as versões “pré” passem nestes testes, pra que a versão final também passe com facilidade.

RdL: No próximo mês (Janeiro), completamos um ano de lançamento da série 2.4 do kernel. A impressão que temos é que, dentre as séries estáveis, esta foi a que mais teve problemas. O que aconteceu?

MT: A culpa é, em parte do Linus <escreve “Linus” com o dedo na mesa>. Não exatamente dele, mas do jeito dele trabalhar. Não estou dizendo que ele está certo ou errado, mas na posição dele eu não faria a mesma coisa. Eu tentaria manter um ritmo de desenvolvimento mais rápido, e estabilizar mais o kernel antes de declará-lo como estável. Na minha opinião ele foi meio “preguiçoso”.

RdL: Não teria sido, em parte, por causa do fato dele aceitar muitas coisas novas nesta versão?

MT: Esse é um dos defeitos dele. Ele aceita as mudanças e vai soltando. Às vezes acho que ele encara o desenvolvimento do kernel como uma grande “brincadeira”. Ele também se esquece muito facilmente do que passou, e dos planos para o futuro. Hoje ele pode dizer “pra resolver o problema A, vamos tentar a solução B”, e amanhã ele pode dizer “pra resolver o problema A, vamos tentar a solução C”. Ele é extremamente inteligente, e quando ele pensa em algo ele consegue pensar em tudo o que pode ser afetado por esta parte. Ele tem uma excelente visão global das coisas, mas a parte “temporal” não é lá muito boa.

RdL: Todos os patches enviados ao kernel são testados? Às vezes tem-se a impressão de que o mantenedor dá uma olhada, diz “É, parece bom!” e aceita.

MT: Na maioria dos casos só de olhar o patch você já tem como saber se ele está correto ou não. Tem também a questão da confiança, se o mantenedor de um driver me envia um patch, eu vou incluí-lo, confiando que o mantenedor sabe o que está fazendo.

RdL: O que você sugere pra alguém que está começando hoje, e quer ajudar no desenvolvimento do kernel?

MT: Em primeiro lugar, aprenda C. Depois, leia um bom livro sobre o assunto, como o Unix Kernel Internals, The New Frontier”. Esse livro é maravilhoso, depois de lê-lo você vai ter na cabeça um “mapa” de como o kernel é estruturado. Depois é só procurar uma área pela qual você se interessa e colocar a mão na massa. Tem muita gente disposta a ajudar os iniciantes, como o pessoal do canal #kernelnewbies, no servidor irc.openprojects.net.

RdL: E quando você passa “oficialmente” a ser o mantenedor do kernel?