Kernel 2.5 em discussão

Desenvolvedores centrais do kernel do Linux estiveram reunidos na Califórnia com convidados como Oracle, SGI e NSA— Agência de Segurança Nacional do governo norte-americano

AUGUSTO CAMPOS
brain@matrix.com.br

O kernel do Linux, iniciado pelo então estudante finlandês Linus Torvalds e desde essa época desenvolvido cooperativamente por usuários do mundo inteiro, sempre foi um excelente exemplo da revolução que a Internet causou: um produto capaz de alterar o equilíbrio do mercado de informática em nível mundial, desenvolvido por pessoas que em geral se conhecem apenas através de e-mail, Web e chats e que não possuem relacionamento formal entre si.

Entretanto, novos tempos trazem novos desafios, e assim surgiu o "Linux 2.5 Kernel Summit", evento fechado realizado em San José, Califórnia, por iniciativa do USENIX e da OSDN, graças ao esforço individual de Theodore Ts’o, que reuniu grande parte dos desenvolvedores centrais do kernel do Linux com convidados importantes, como representantes da Oracle, da SGI e NSA, Agência de Segurança Nacional do governo norte-americano.

O grupo de participantes incluiu nomes conhecidos até mesmo entre os usuários de Linux que não se interessam particularmente pelo desenvolvimento do kernel, tais como Linus Torvalds, Alan Cox, Eric Raymond, além de outros nomes bastante conhecidos pelos insiders, como Paul Mackerras, Stephen Tweedie, Andrea Arcangeli e Rik van Riel. O Brasil também estava representado na seleta lista de 65 participantes do evento, com a presença de Arnaldo Carvalho de Melo e Marcelo Tosatti, além do próprio Rik van Riel, que atualmente reside em terras tropicais.

Por que uma reunião?

O kernel 2.4 (estável) foi lançado no início deste ano, e em geral uma nova série de desenvolvimento surge logo em seguida (para mais detalhes consulte a matéria de capa da RdL 13), permitindo o avanço do Linux sem comprometer a estabilidade da série corrente. E esse foi o fato que motivou esse encontro sem precedentes dos desenvolvedores centrais do kernel: discutir que rumos dar à série 2.5, quais os problemas atuais que precisam de mais atenção, e quais as oportunidades que estão surgindo. O evento se constituiu em uma seqüência de apresentações e discussões, em que todos os interessados tiveram oportunidade de se manifestar sobre os assuntos nos quais interferem. É necessário destacar que o desenvolvimento do Linux continua sendo um processo aberto e comunitário, e que esse evento aberto a apenas 65 pessoas significa apenas isto: uma reunião para troca de idéias, visando identificar quais os problemas e o que fazer — o "como" fazer fica para mais tarde. As sugestões, colaborações, idéias, relatos e críticas continuam funcionando como sempre foram, abertos ao público em geral pela Internet.

Segundo Arnaldo Carvalho de Melo, desenvolvedor brasileiro e responsável pelo Kernel Janitor Project, o evento valeu a pena, pois ao mesmo tempo em que todos puderam conhecer pessoalmente outros colegas que até então eram apenas nomes, logins e e-mails, tiveram ainda a oportunidade de conviver uns com os outros, o que traz maior liberdade para discutir os assuntos do interesse da área de responsabilidade de cada um.

A pauta

Não seria possível esgotar neste espaço todos os temas discutidos no evento, portanto apresentaremos apenas os destaques. No quadro "Para saber mais" você encontrará mais referências, incluindo gravações em Real Audio das apresentações.

A primeira apresentação foi da Oracle, o que pode ser uma surpresa para muitos. Mas essa empresa desenvolve, mantém e suporta uma linha de produtos com necessidades específicas e que rodam em máquinas high-end, as mesmas que costumam receber bastante atenção quando se planeja o futuro do Linux — até porque as máquinas high-end de hoje podem estar muito mais acessíveis quando a série 2.5 gerar o Linux 2.6 estável. O representante da Oracle elencou alguns dos obstáculos ao desempenho de aplicações que rodam sobre Linux em plataformas superiores, incluindo a estratégia de lock para operações de E/S, a necessidade de acesso assíncrono a dispositivos de armazenamento (cujo desenvolvimento foi apresentado no dia seguinte por Ben LaHaise), e uma implementação mais eficiente de semáforos. Segundo o registro no diário de Alan Cox, um dos expoentes do kernel, a maior parte dos desejos da Oracle tem a ver com a otimização do seu produto, mas alguns deles fazem sentido para aplicações em geral e têm grandes chances de implementação.

Stephen Tweedie conduziu uma discussão sobre os problemas atuais com o acesso a dispositivos de bloco (como os discos). Por exemplo, atualmente o Linux pode endereçar até 2Tb por dispositivo, o que parece muito, mas já está sendo alcançado e superado por discos RAID. Outro problema identificado é a granularidade do tratamento de erros — atualmente o kernel não qualifica as falhas, não diferenciando um bloco defeituoso de um disco inutilizável, o que prejudica algumas decisões, inclusive no que diz respeito a sistemas RAID. Tweedie também tratou de problemas de desempenho, complementando a exposição da Oracle.

Logo em seguida, Steve Lord apresentou algumas características do sistema de arquivos de alto desempenho XFS (da SGI) que poderiam ser incluídas no sistema de arquivos virtual (VFS) do Linux visando aumentar o desempenho das operações de escrita.

A versão corrente do kernel tem problemas sérios de desempenho quando exposto a tráfego de rede excessivamente alto. Jamel Hadi Salim expôs as razões dessa falha, e sugeriu mudanças de arquitetura que permitam fazer com que o tratamento da carga excessiva ocorra como deveria ser: tratar os pacotes que puderem ser tratados, e rejeitar ou ignorar o excesso sem desperdiçar recursos nesse processo.

A quantidade de periféricos de PC que seguem algum tipo de padrão hot-pluggable só tem aumentado, e vai se tornar mais comum — do mouse ao disco rígido, é cada vez mais freqüente você poder incluir e retirar equipamentos sem tirar a máquina do ar.

Johannes Erdfelt, mantenedor do suporte a USB no kernel, apresentou as questões associadas ao tratamento de tecnologias tão diversas quanto USB, PCI, Firewire e SCSI no que diz respeito a tratamento de dispositivos hot plug. Há necessidade, entre outras coisas, de carregar o driver correto para cada dispositivo, e de criar o arquivo de device com um nome consistente, preservando atributos como as permissões de acesso e o seu proprietário. Existem alternativas para isso, mas a questão tem sido controversa, e promete continuar sendo.

O segundo dia do evento começou com uma apresentação de Eric Raymond sobre o atual modelo de configuração do kernel — os familiares "make config", "make dep" e similares. O modelo atual tem falhas conceituais e de implementação, e seria mais fácil criar um novo do que consertar o atual, segundo ele. E, de fato, Raymond já está envolvido em fase bem adiantada de desenvolvimento do CML2, novo esquema de configuração do kernel, criado em Python e com muitas vantagens sobre o modelo atual, mas nada foi definido até o momento.

Outra equipe está cuidando do problema da compilação do kernel e apresentou um novo modelo com bastante chance de também ser adotado. No novo modelo, não haverá necessidade de compilar os módulos em um passo separado da compilação do kernel em si, e a instalação do novo kernel gerado também ficará mais transparente. O tratamento de dependências também muda, ficando mais racional e seguro. E será possível incluir código que não resida diretamente na árvore de diretórios do fonte do kernel (o que deverá facilitar a vida de desenvolvedores e também de quem costuma aplicar patches externos) e compilar a partir de fontes sem permissão de escrita (como CD-ROMs).

Logo em seguida, Rik van Riel apresentou a situação atual do sistema de memória virtual, incluindo a lista dos problemas que vêm sendo enfrentados, e as possíveis soluções. É provável que em breve vejamos o kernel do Linux gerenciando páginas de memória maiores que os atuais 4k ou 8k, e trazendo com isso mais desempenho. Riel abordou ainda os possíveis deadlocks em caso de extrema falta de memória livre e de como o Linux trata o excesso de acesso à memória virtual (thrashing).

Outros temas tratados no evento foram alternativas (como o Subversion e o Bitkeeper) ao gerenciamento de versões, atualmente controlado pelo sistema CVS, e mudanças na forma de administrar o desenvolvimento do kernel, incluindo a fixação de datas para a estabilização e lançamento de versões.

Esse tipo de evento demonstra que, mesmo tendo alcançado esse novo status de aceitação, o kernel continua sendo tão livre quanto sempre foi — e, para muitos, isso é o que realmente faz a diferença.