Modernizando um driver de kernel de 25 anos com Claude Code
(dmitrybrant.com)- O driver ftape é o único driver de kernel open source para Linux capaz de recuperar dados de fitas de backup (QIC-80) dos anos 1990
- Porém, esse driver não recebia manutenção desde depois de 2000, então só podia ser usado em ambientes Linux antigos
- Com o Claude Code, o autor refatorou o código-fonte legado para adequá-lo ao kernel Linux atual e o converteu com sucesso em um módulo de kernel independente
- No processo, o Claude converteu automaticamente funções e estruturas obsoletas para APIs modernas, enquanto o usuário analisou manualmente a saída para corrigir alguns erros de configuração
- A experiência de usar um agente de programação com IA trouxe insights sobre amplificação da capacidade do programador e sobre como fazer onboarding mais rápido em novas tecnologias e frameworks
Contexto: recuperação de fitas de backup antigas e o driver ftape
- Recuperar dados de cartuchos de fita como QIC-80 é um dos hobbies do autor
- Essas fitas normalmente exigem um drive de fita especial conectado ao controlador de disquete
- Esses drives eram usados principalmente nos anos 1990 por pequenas empresas ou usuários individuais para backup
- Usar o controlador de disquete permitia uma implementação barata sem adaptador SCSI dedicado, mas havia várias desvantagens, como limite de velocidade (500 Kbps) e um protocolo não padronizado
- Para se comunicar com esse dispositivo de fita, no Linux o driver de kernel ftape é indispensável
- Como apenas o ftape consegue ler os dados binários brutos puros, ele é essencial para a recuperação
- Porém, o driver ftape não recebia manutenção desde por volta de 2000, e por isso não podia ser usado em kernels Linux modernos
- Assim, sempre que precisava recuperar dados, o autor tinha de inicializar manualmente um Linux antigo, como o CentOS 3.5
Começando a modernização do driver de kernel com Claude Code
- O autor pediu ao Claude Code, junto com a descrição do repositório, para modernizar o driver para que ele pudesse ser compilado em kernels atuais
- O Claude identificou e substituiu funções e estruturas obsoletas de acordo com a API e a estrutura atuais do kernel
- Após várias rodadas de feedback e ajustes manuais, o código do driver passou a compilar sem erros
- O código inicial só podia ser compilado dentro da árvore completa de código-fonte do kernel, mas, após um pedido adicional, o Claude também gerou automaticamente um sistema de build para módulo externo independente
- Com isso, tornou-se possível criar separadamente o módulo de kernel em arquivo
.ko, iniciando os testes com o hardware real conectado
- Com isso, tornou-se possível criar separadamente o módulo de kernel em arquivo
Processo de resolução de problemas
- O módulo de kernel era carregado corretamente, mas surgiram problemas de detecção e comunicação com o drive
- Como as tarefas exigiam privilégios sudo, o Claude não podia executar os testes repetidamente por conta própria, então o autor forneceu manualmente os logs do
dmesgpara rastrear o problema
- Como as tarefas exigiam privilégios sudo, o Claude não podia executar os testes repetidamente por conta própria, então o autor forneceu manualmente os logs do
- Ao comparar os logs com casos anteriores bem-sucedidos, o Claude encontrou um bug relacionado à falta de configuração do endereço padrão da porta de I/O e à inicialização de parâmetros
- O valor padrão foi convertido de -1 para
0xffff, causando falha na detecção; redefinir o endereço corretamente resolveu o problema
- O valor padrão foi convertido de -1 para
- No fim, o módulo passou a ser carregado corretamente e foi bem-sucedido o dump de dados de uma fita de teste
O que a experiência mostra sobre colaboração com agentes de programação com IA
- A interação com o Claude Code pareceu "uma colaboração com um desenvolvedor júnior", dando a sensação de trabalhar com um engenheiro real
- O usuário ainda precisa liderar ativamente decisões de arquitetura, descoberta de problemas e direcionamento
- Quanto mais palavras-chave específicas do domínio e solicitações concretas forem usadas, melhores os resultados
- A produtividade do agente de IA aumenta muito quando ele recebe o tipo certo de tarefa, então é importante ter noção de suas limitações e pontos fortes
- A IA dobrou a capacidade do autor. Um trabalho que manualmente levaria semanas foi concluído em poucos dias apenas com conversas e feedback rotineiros
- Nesse processo, ele também aprendeu habilidades realmente úteis, como práticas modernas de desenvolvimento de kernel, arquitetura x86 e novas ferramentas de linha de comando
- O autor destaca que isso acelera muito o onboarding e a adaptação inicial a novos frameworks, como Rust e Flutter
Conclusão: ftape volta à vida
- Depois de 25 anos, o ftape voltou a poder ser compilado e usado em versões modernas do Linux
- O autor continua trabalhando em melhorias adicionais e testes, e também confirmou suporte a dispositivos baseados em porta paralela, além dos drives baseados em disquete
- O hardware físico continua praticamente o mesmo de antes, mas o sistema operacional mudou de CentOS 3.5 para Xubuntu 24.04
Referência
- O código-fonte do projeto ftape está disponível no GitHub
- A lista de equipamentos de coleção do autor e outros detalhes podem ser vistos em seu blog pessoal
1 comentários
Opiniões no Hacker News
Eu carreguei o módulo manualmente e fiquei copiando e colando a saída do
dmesgno Claude repetidamenteUm dos principais motivos de eu usar o Claude é que ele consegue iniciar processos de longa duração, ler a saída deles e depurar com base nisso
Havia várias formas de hackear isso para pular a etapa manual — por exemplo, enviar o
dmesgpara uma porta UDP local e fazer o Claude iniciar um listenerAcho que é um bom exemplo
Vejo dois efeitos principais ao usar esse tipo de ferramenta
Primeiro, em frameworks com os quais eu já estou familiarizado, o Claude faz pattern matching das partes repetitivas rapidamente e aumenta muito minha produtividade
Segundo, ao aprender frameworks novos, também dá para fazer onboarding muito mais rápido — isso ajuda especialmente em grandes empresas que usam stacks variados
Para entender de verdade a capacidade da IA, é preciso investir bastante tempo em tecnologias e frameworks que mudam rápido
Se você não usou o Claude Code ou o Claude 4.0 por mais de 100 horas, talvez ainda não tenha percebido todo o potencial
O cenário de “alguém que não é programador codando no feeling e se metendo em problemas” provavelmente é comum no X (antigo Twitter), mas para desenvolvedores experientes que dedicam tempo de forma consistente, a experiência é completamente diferente
Esse é o ponto central
Eu uso o Claude Code todos os dias, sem falta, como ferramenta principal para mudanças em codebases existentes
Depois de muita tentativa e erro, criei meu próprio processo, e isso aumentou bastante minha produtividade e minha disposição para encarar experimentos grandes
Gosto especialmente de como, depois que eu defino antes as estruturas de dados, esquemas e APIs internas, o Claude Code quase sempre consegue montar muito bem a UI de ferramentas internas de uma vez só
Isso me permitiu pensar de forma mais abstrata, longe de trabalho repetitivo ou da complexidade dos frameworks, e foi um grande ponto de virada em 16 anos de carreira
Exato
O autor basicamente pediu ao Claude para portar um driver de Linux 2.4 para 6.8
Como existe bastante material relevante online, o Claude deu conta da maior parte do trabalho, e a expertise do autor só foi necessária nas partes realmente complexas e centrais
A ideia de “usar a IA como ferramenta para amplificar explosivamente as próprias habilidades” faz muito sentido aqui
Se sua capacidade inicial aqui for 0, multiplicar por IA ainda vai resultar em algo próximo de 0, ou até em produtividade negativa
No nosso time também tem gente usando LLM para se jogar sem medo em áreas novas, mas mesmo quando damos o Claude 4 thinking agent para todo mundo, ainda sai muita coisa sem pé nem cabeça
Se você passou a maior parte da carreira de programação se apoiando em pattern matching, aí o agente de LLM só está fazendo mais pattern matching em cima disso, e para colegas sem esse tipo de vivência isso acaba sendo mais dor de cabeça do que ajuda
Agentes de LLM fazem o pattern matching que humanos conseguem fazer, só que muito mais rápido, mas no geral não parecem ser particularmente melhores que humanos nisso
Não serve só para explorar frameworks novos, mas também linguagens novas
Nosso time usa Ruby, e como Ruby é fácil de ler, eu nem preciso aprender a sintaxe a fundo; posso simplesmente pedir para o LLM escrever o código e eu tomo as decisões
Mesmo sem saber Ruby, consigo escrever imediatamente código em um nível aceitável para o time, o que me permite ser produtivo logo de cara em um ambiente desconhecido
(Observação: os colegas revisam os Pull Requests)
A frase “ferramenta para amplificar explosivamente suas habilidades” ficou muito concreta para mim esta semana, enquanto eu criava repetidamente um pequeno projeto umas 10 vezes
O valor da IA aparece de verdade quando ela gera coisas meio bagunçadas e eu entro guiando para consolidar markup, estilos, JS etc. de forma limpa
Em ambientes como startups, onde as convenções de código costumam ser fracas, é difícil aplicar pedidos baseados em pattern matching, mas imagino que em codebases fortes e maduras o efeito seja totalmente diferente
Acho que é preciso escrever prompts com o máximo de especificidade possível, usando palavras-chave bem específicas do domínio
Se faltar entendimento técnico sobre uma linguagem ou framework em particular, isso gera ambiguidade no prompt, e o LLM tende a preencher essas lacunas arbitrariamente, o que facilita resultados diferentes da intenção original
Essa ambiguidade é justamente a origem dos bugs
Esse é o outro lado da “amplificação explosiva”
Ao ler textos assim, fico pensando que, antes da adoção dos LLMs, a quantidade de trabalho realmente executada era absurdamente baixa em relação à demanda
Eu ainda acho que o gargalo não é a “execução”, e sim ideias com viabilidade de mercado
Não existem tantas coisas pelas quais as pessoas realmente queiram pagar
O problema nem sempre é falta de trabalho, e sim falta de gente com a base técnica e a experiência prévia necessárias para fazê-lo
Se você não tiver experiência com desenvolvimento de kernel, dificilmente vai conseguir resultados como os do autor só com bons prompts
Em teoria, parece que seria possível “modernizar” todos os drivers antigos para kernels atuais com a ajuda de LLMs, mas na prática sempre é necessária supervisão humana de alguém experiente, e o número real desses especialistas é minúsculo em comparação com a quantidade de drivers que precisam ser mantidos
Há uma boa conversa e entrevista com Alan Kay e Joe Armstrong em que eles mencionam os problemas que surgem porque a maior parte do código não é desenvolvida com uma especificação, de forma que bastaria trocar o alvo e compilar
Se existisse uma spec formal além do código, migrar o driver para um novo kernel seria algo fácil, como “recompilar a especificação”
Mas como hoje o ponto de partida não é uma spec, e sim código antigo, o LLM acaba apenas fazendo pattern matching com código parecido, sem realmente entender nem garantir o significado — e por isso a habilidade humana continua indispensável
Eu já tinha a sensação de que a IA reduziria a barreira de entrada para kernel hacking
E cada vez mais sinto que isso é verdade
Em breve talvez vejamos um suporte muito mais amplo a hardware embedded/ARM e até novos sistemas operacionais para dispositivos inteligentes leves
Só que a maioria pede para a IA “construir a casa inteira”, quando na verdade o mais eficaz é usá-la como algo que “ajuda a martelar”
Acho que este é um bom exemplo de um desenvolvedor que entende bem o papel e os limites da IA e a usa da forma adequada
Fiquei especialmente impressionado com o ceticismo dele ao decidir transformar o driver em um módulo separado
Quero destacar uma “pista importante” que ninguém mais mencionou
O autor diz claramente: “eu já tinha alguma experiência com módulos de kernel e sei bem C, então não se deve superestimar o resultado do Claude”
Ou seja, não foi como se o módulo de kernel tivesse ficado pronto de verdade depois de só três perguntas; houve várias rodadas de conversa e o código foi corrigido manualmente muitas vezes
Ele afirma que, sem entender a estrutura interna básica de um módulo de kernel, a modernização nunca teria sido possível — e esse é um contexto que precisa ser levado em conta ao usar qualquer ferramenta de geração de código
Ele também escreveu que colaborar com o Claude Code parecia “como trabalhar com um engenheiro júnior”; ele faz qualquer coisa que você pedir, e quando você aponta um erro ele pede desculpas e elogia você na hora, o que parece mais bajulação do que comportamento de um engenheiro de verdade
Por fim, o autor diz que “se realmente quisesse, poderia ter feito esse trabalho sozinho, mas teria precisado reaprender como se desenvolvia para kernels de 25 anos atrás”
No fim das contas, isso reforça que a essência do trabalho de modernização é “entender com precisão a solução legada e identificar o que é necessário”
E também acho interessante que a vantagem destacada seja justamente poder pular esse aprendizado
Acho ótimo quando o agent me explica projetos que eu não conheço
Recentemente clonei o código-fonte do Firefox e usei o qwen-code para perguntar sobre os recursos de IA do Firefox e como eles são implementados, e aprendi muito bem assim
O jeito de aprender ficou muito mais legal
Acho que isso representa uma mudança que dá mais poder às pessoas
O autor já vinha fazendo side projects com paixão há muito tempo, e um upgrade nas ferramentas é realmente algo muito bom
Só que, quando a área é específica demais, a comunidade pode não oferecer suporte suficiente, e aí o LLM ajuda a resolver problemas personalizados
As barreiras de entrada estão caindo cada vez mais, e vai chegar uma época em que até pessoas com menos bagagem técnica conseguirão resolver por conta própria problemas mais simples e bem específicos
É uma mudança positiva, que permite que mais gente tente
Fiquei curioso sobre como a velocidade mudou depois do upgrade