A mais recente versão do Linux - o Kernel 2.6.23, ocorrida apenas três meses depois da última atualização - refletiu um grande número de mudanças. Para um usuário corporativo do Linux, o desenvolvimento de seu kernel pode parecer muito complicado, com dezenas de pessoas dedicadas à manutenção de diferentes partes e mais centenas de voluntários encaminhando código, o que é difícil de se perceber, quando recursos são lançados.

Não existe um roteiro para o Linux, propriamente dito. Para se ter uma noção do processo, leia abaixo sete áreas de desenvolvimento que valem a pena observar, com base em entrevistas realizadas com desenvolvedores e mantenedores do kernel e no conteúdo do site www.kernelnewbies.org. Nem todas estão progredindo lentamente, ilustrando o caminho repleto de "paradas e saídas", que os aperfeiçoamentos precisam percorrer para serem incluídos no kernel.

1. Virtualização
Reconhecendo a virtualização como uma megatendência da década, os mantenedores do kernel do Linux tornaram uma prioridade acrescentar, rapidamente, recursos de virtualização ao kernel. O hipervisor KVM, que foi uma contribuição de Avi Kivity, da companhia iniciante, Qumranet, foi incluído no kernel no fim de 2006 e atualizado na versão do mês passado. Mas este é um exemplo do conflito entre as rápidas inovações para o kernel e as edições corporativas, que avançam mais lentamente.

"O KVM é um bom exemplo de recursos que acreditamos que ainda não estão prontos para o uso corporativo", avalia Holger Dryoff, vice-presidente de gerenciamento, na Novell. O KVM precisa ser submetido a mais testes sobre o modo como ele interage com os subsistemas do kernel, incluindo o scheduler, antes de ser incluído no SUSE Linux Enterprise Server.

A XenSource, uma companhia comercial de virtualização de código aberto, recentemente adquirida pela Citrix Systems por US$500 milhões, formou parceria para conseguir inserir o hipervisor Xen no kernel com sua própria arquitetura, assim como aconteceria com um novo chip.

Os mantenedores do Kernel contestaram, dizendo que esse é um método para acrescentar recursos de virtualização que tem uma difícil manutenção. Os engenheiros da XenSource concordaram, mas continua o trabalho no sentido de manter o Xen alinhado com as operações do kernel. Ele não foi produzido no kernel; além disso, a compatibilidade recém-acrescentada permite que o Linux reconheça quando está sendo executado em um ambiente virtualizado.

Outros recursos de virtualização estão progredindo mais rapidamente, como o KVM e o Lguest, um hipervisor minimalista, com 5.000 linhas, escrito pelo engenheiro da IBM, Rusty Russell, que foi incluído no kernel mais recente. Assim como o KVM, ele aproveita os vínculos com a virtualização dos mais recentes chips da Intel e da Advanced Micro Devices.

No entanto, diferentemente do ESX Server, da VMware, o Lguest cria uma máquina virtual cujo sistema operacional percebe que foi virtualizado. Esta arquitetura permite que o sistema operacional transfira, com mais eficiência, algumas solicitações para os ciclos da CPU, diretamente para o hardware, em vez de retardar o processo, agindo como um intermediário.

2. Operações em tempo real
As operações em tempo real do Linux estão sendo rapidamente aprimoradas e, atualmente, ele é um sistema integrado freqüentemente utilizado em telefones celulares e outros dispositivos. Mas o kernel 2.6.23, lançado recentemente, mostra "uma pequena regressão" nas operações em tempo real, explica Jim Ready, diretor de tecnologia e fundador da MontaVista, uma fabricante comercial de Linux integrado.

Um novo scheduler (organizador de cronograma) de processos tende mais para a "igualdade" - a noção de que as tarefas que o usuário final diz que o processador tem de fazer precisam ter maior prioridade.

"Quem se preocupa com operações em tempo real não quer saber de igualdade", relata Ready, uma vez que os defensores das operações em tempo real querem que o sistema operacional interrompa o que quer que a CPU esteja fazendo e estabeleça uma nova prioridade.

Um exemplo simples é o do software em um equipamento de medicina, que monitora a respiração dos pacientes, e deve enviar um alerta imediato, em caso de uma parada respiratória, interrompendo qualquer processo que o software esteja realizando. A MontaVista não vai incorporar o novo kernel em sua linha de produtos até que seu desempenho seja melhorado, confirma Ready. O analista do Gartner, George Weiss, prevê que o Linux padrão será competitivo como um sistema de operação em tempo real, em 2008.

3. Controladores de interrupção
Uma razão que Weiss pode citar é porque os desenvolvedores do kernel estão trabalhando para dar ao responsável pelo scheduler outro recurso em tempo real. Uma importante função de um sistema operacional é gerenciar as interrupções - a fim de decidir que tarefas devem receber atenção da CPU e como priorizar diferentes ações. Se todos os controladores de interrupções podem ser combinados em sua própria seqüência, ela pode ser programada e priorizada, em vez de ocorrerem respostas em tempo real imprevisíveis e atrasadas.

O trabalho nessa abordagem ainda deverá demorar cerca de três anos. Sven-Thorsten Dietrich, da MontaVista, encaminhou código em 2004, na esperança de evitar que os controladores de interrupções utilizassem o kernel para tarefas de rotina, uma vez que isso prejudica a resposta em tempo real.

Mas esse código era complicado demais para ser aprovado por Ingo Molnar, o especialista em scheduler do kernel. O código "esbarrou" em um importante recurso do kernel, os spinlocks (bloqueadores de ciclo), que "paralisam" a CPU, enquanto um processo espera por um bit de dados ou um evento necessário. Muitos processos dependem dos spinlocks. O código de Dietrich reduziu centenas de spinlocks para 30; a revisão de Molnar manteve 90 spinlocks, uma mudança menos incômoda.

O conjunto de controladores de interrupções em uma seqüência (thread) separada, agora, parece estar pronto para ser inserido no kernel. "Ingo substituiu o que fizemos, mas seu trabalho é bom", ressalta Ready. A MontaVista não se importaria em receber maior crédito pelo trabalho que fez, mas Ready sabe que é assim que a colaboração em fonte aberta funciona, e ele defenderá o desenvolvimento de mudanças em tempo real no kernel.

4. Segurança
Todo mundo quer ter sistemas mais seguros. A Novell distribui o AppArmor, com seu SUSE Linux Enterprise Server 10 como um meio de limitar o quanto de um sistema operacional um aplicativo pode acessar e, desse modo, restringindo os possíveis danos, caso o aplicativo seja acessado sem autorização. Contudo, não é provável que ele seja incluído no kernel tão depressa.

Uma importante autoridade em segurança do Linux, Stephen Smalley - desenvolvedor de outro esquema de segurança, o SELinux -, argumenta que o AppArmor não pode ser inserido no kernel porque seu mecanismo protetor é baseado em um esquema de lista em branco, pelo qual o AppArmor permite acesso somente aos arquivos nomeados para um aplicativo, e todos os outros são excluídos. De acordo com um relatório divulgado no ano passado por Jonathan Corbet, Smalley acredita que um habilidoso intruso poderia utilizar os nomes de caminho aprovados para adivinhar outros nomes, criando uma exposição indesejada.

O mantenedor do kernel, Andrew Morton, concorda que essa objeção fundamental à abordagem utilizando nomes de caminho manteve o AppArmor fora do kernel. "Não sou programador de segurança", ele explica. "Não sei como resolveria isso."

5. Diagnósticos de sistema
A Solaris tem o DTrace para descobrir o que está acontecendo no núcleo do sistema operacional, mas o Linux quase não tem ferramentas de diagnóstico disponíveis para os usuários. Uma das poucas ferramentas existentes é o ptrace, que permite que um processo rastreie as ações de outro.

Mas o ptrace é difícil de se utilizar e propenso a erros; e agora, uma substituição, o utrace, tornou o ptrace tão distante quanto a árvore de gerenciamento de memória, de Morton, um dos últimos obstáculos a superar, antes de encaminhar a Linus Torvalds. O utrace pode rastrear o comportamento de um processo enquanto ele é executado por um programa, sem alguns dos problemas causados pelo ptrace, mas ele ainda provoca problemas de bloqueio no kernel. Corbet prevê que sua inclusão provavelmente não ocorrerá no próximo kernel.

6. Sistemas de arquivos
O sistema de arquivos Reiser4 vem sendo avaliado quanto à sua possibilidade de inclusão no kernel, que já contém 30 sistemas de arquivos. Trata-se de um grande sistema de gerenciamento de arquivos, bom em lidar com um grande número de arquivos pequenos, enquanto utiliza o mínimo de espaço em disco, de acordo com a documentação de Hans Reiser.

O sistema de arquivos exige que uma operação de arquivo seja concluída ou cancelada, eliminando o perigo de arquivos serem corrompidos por operações não totalmente concluídas. Ele parece ser ideal para muitos usos do Linux, mas depois de anos de debate, o Reiser4 não foi incluído no kernel.

Ele não se ajusta bem a determinadas partes do kernel, e Reiser desistiu de sua posição como um importante desenvolvedor. "O sistema precisará de um novo "defensor", para que possa, eventualmente, se tornar parte do Linux", escreveu Corbet, em sua previsão sobre as perspectivas do Linux, publicadas no início deste mês.

O ZFS, um sistema de arquivos de 128 bits, da Sun Microsystems, multiplica o espaço de endereçamento do Linux para além da necessidade dos grandes sistemas atualmente utilizados. Seus admiradores indicam que seu código de fonte aberta deveria ser considerado para o kernel. Mas sua licença atual não é compatível com o Linux GPL.

7. Gerenciamento de energia
O Linux está atrasado, no que se refere ao gerenciamento de energia; um aspecto no qual os laptops utilizando o Windows demonstraram um impressionante avanço, incentivando os engenheiros da Intel; os desenvolvedores do kernel, Molnar e Thomas Gleixner, e outros, a se dedicarem mais a obter progresso. Há um ano, o kernel se tornou "menos resistente ao estado inativo", comunicando que o processador deve permanecer em um estado inativo, quando não existir trabalho a ser feito. Sem esse recurso, a freqüência da CPU perguntaria ao kernel, um total de mil vezes por segundo, se há alguma tarefa a realizar, consumindo mais energia eletricidade.

Dirk Hohndel, diretor de tecnologia para o Linux, na Intel, espera mais melhorias no gerenciamento de energia. Mas qualquer modificação entre o kernel e a freqüência do sistema ameaça muitas outras interações. "Esses são aspectos muito difíceis de serem resolvidos e também demoram muito", ele conclui. "E creio que esse é o modo certo de agir."

Fonte: ITWEB