page102
O Kernel Linux não tem uma API interna estável, e para os que desejam que venha a ter, podem esquecer! Alguns anos atrás, os desenvolvedores do Kernel descreveram por que o Linux não tem uma API no Kernel e publicaram dentro do código-fonte do próprio Kernel, no seguinte arquivo:
http://www.kernel.org/doc/Documentation/stable_api_nonsense.txt
Para os que tiverem alguma dúvida, por favor, leiam este arquivo. Ele explica porque o Linux não tem uma API estável para o Kernel e porquê nunca terá. Se o processo de comunicação interna entre funções do Kernel fossem “congelados”, a constante evolução do código interno seria inviável.
Um exemplo mostra como tudo isso funciona. O código de suporte a USB foi reescrito ao menos três vezes no Kernel Linux. Isso foi feito ao longo do tempo, a fim de lidar com demandas que originalmente não foram necessárias, como o reconhecimento de dispositivos de alta velocidade, bem como aportar melhorias para correção de bugs e instruções de segurança.
Cada vez que mudanças foram feitas na API, todos os drives do Kernel que precisam usar a API precisam também ser corrigidos, para que não parem de funcionar. Por conta deste tipo de cuidado, o Linux comprovadamente tem os acessos mais rápidos de barramento USB, quando comparado com qualquer sistema operacional. O objetivo final destas correções e alterações é permitir que o dispositivo USB tenha o acesso mais rápido quanto possível.
Com o sistema “…” o processo é um pouco distinto. Na versão “XP”, o código de acesso a USB foi reescrito ao menos 3 vezes. Com o “Vista”, 4 vezes. Com o “7”, 3 vezes. Com o “8”, ao menos uma atualização já foi disponibilizada. Para conferir, pode-se pesquisar no seu buscador a expressão “Update stack-USB + ...”, onde os “...” é o nome da versão do sistema que se deseja buscar a informação. Contudo, cada vez que este retrabalho é feito, novas funções são adicionadas e correções no código existente são feitas. Mas sem ignorar de que todo um suporte a funções antigas da API precisam ser mantidas – mesmo com falhas, sob o risco de quebrar a compatibilidade a versões anteriores. Os desenvolvedores do sistema “...” também não tem acesso ao código de todos os diferentes
ESPAÇO ABERTO
ARTIGO