I’m sure that if I really wanted to, I could have done this modernization effort on my own. But that would have required me to learn kernel development as it was done 25 years ago. This would have probably taken me several weeks of nonstop poring over documentation that would be completely useless knowledge today.
Certes, il n'aura pas d'application immédiate de ce qu'il aurait pu apprendre du développement du noyau tel qu'il était il y a 25 ans. Néanmoins il n'est pas totalement inutile d'acquérir des connaissances sur les méthodes du passé. Cela lui aurait permis de mieux comprendre pourquoi les choses sont faites telles qu'elles le sont aujourd'hui et pourquoi elles seront encore différentes demain.
J’ai toutefois du mal à croire que pour un driver de lecture de périphérique, dont on se fout des droits j’imagine, cela est évolué au point que ce soit complètement différent en terme de logique.
Donc il n’aurait probablement rien « appris ». Juste à trouver les changements d’API avec les options obsolètes et les nouvelles structures.
Toutefois il dit bien qu’il s’est fait aidé par le LLM mais qu’une personne n’ayant jamais fait de driver noyau n’aurait jamais pu se faire aider. Il est probable que le temps investi par rapport au gain n’en valait pas la chandelle sans aide. En gros, seul, il aurait peut-être abandonné avant d’avoir quelque chose qui marche. Mais à deux cerveaux humains qui s’entraident ça aurait pu également fonctionner peut-être…
J’ai toutefois du mal à croire que pour un driver de lecture de périphérique, dont on se fout des droits j’imagine, cela est évolué au point que ce soit complètement différent en terme de logique.
Oui pour un pilote sauf si ça utilise un sous système compliqué qui a évolué a souvent peu besoin d'une refonte en profondeur. Le plus dur c'était de l'avoir fonctionnel à la base, après c'est le jeu de voir les évolutions d'API.
Ce serait un code plus fondamental tel qu'un sous système entier cela pourrait être une autre paire de manche.
Toutefois il dit bien qu’il s’est fait aidé par le LLM mais qu’une personne n’ayant jamais fait de driver noyau n’aurait jamais pu se faire aider. Il est probable que le temps investi par rapport au gain n’en valait pas la chandelle sans aide. En gros, seul, il aurait peut-être abandonné avant d’avoir quelque chose qui marche. Mais à deux cerveaux humains qui s’entraident ça aurait pu également fonctionner peut-être…
En fait son article est bizarre. De ce que j'ai compris le gars a quand même un bagage très honorable en C. Pour écrire un pilote noyau il n'y a pas besoin de beaucoup plus. Comme il le dit lui même, cela démystifie le noyau en un sens, le noyau n'est pas aussi mystique qu'un autre projet. Écrire un pilote noyau basique est limite plus simple que de contribuer à de nombreux projets qui ont l'air plus simple en apparence en espace utilisateur. Peut être que s'il avait fait tout tout seul cela ne lui aurait pas pris tant de temps que cela en plus avec des connaissances en C suffisante.
Je suis également étonné qu'il dise que faire cela lui aurait surtout nécessité de comprendre du code ancien et inutile. Il a peut être en partie raison, mais de l'autre il aurait malgré tout eu besoin de lire ou écrire du code noyau moderne ce qui est pour le coup plus utile. D'ailleurs il semble dire qu'il fera du code noyau récent à l'avenir donc ce n'est pas si inutile de se plonger dans ce genre d'exercices à mon sens car le volet moderne du code reste valorisable.
J'aime bien en tout cas la problématique de base que je trouve intéressante.
Unfortunately I accidentally committed a bunch of unnecessary metadata files (.cmd and .symvers), which makes the commits look a bit messy. It's really just the changes to .c files and makefiles that are relevant.
# Lu
Posté par Julien Jorge (site web personnel) . Évalué à 6 (+4/-0).
Certes, il n'aura pas d'application immédiate de ce qu'il aurait pu apprendre du développement du noyau tel qu'il était il y a 25 ans. Néanmoins il n'est pas totalement inutile d'acquérir des connaissances sur les méthodes du passé. Cela lui aurait permis de mieux comprendre pourquoi les choses sont faites telles qu'elles le sont aujourd'hui et pourquoi elles seront encore différentes demain.
Bon article au demeurant.
[^] # Re: Lu
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 3 (+1/-0). Dernière modification le 09 septembre 2025 à 15:24.
Oui l’article est très bon (mais un peu long).
J’ai toutefois du mal à croire que pour un driver de lecture de périphérique, dont on se fout des droits j’imagine, cela est évolué au point que ce soit complètement différent en terme de logique.
Donc il n’aurait probablement rien « appris ». Juste à trouver les changements d’API avec les options obsolètes et les nouvelles structures.
Toutefois il dit bien qu’il s’est fait aidé par le LLM mais qu’une personne n’ayant jamais fait de driver noyau n’aurait jamais pu se faire aider. Il est probable que le temps investi par rapport au gain n’en valait pas la chandelle sans aide. En gros, seul, il aurait peut-être abandonné avant d’avoir quelque chose qui marche. Mais à deux cerveaux humains qui s’entraident ça aurait pu également fonctionner peut-être…
[^] # Re: Lu
Posté par Renault (site web personnel) . Évalué à 5 (+2/-0).
Oui pour un pilote sauf si ça utilise un sous système compliqué qui a évolué a souvent peu besoin d'une refonte en profondeur. Le plus dur c'était de l'avoir fonctionnel à la base, après c'est le jeu de voir les évolutions d'API.
Ce serait un code plus fondamental tel qu'un sous système entier cela pourrait être une autre paire de manche.
En fait son article est bizarre. De ce que j'ai compris le gars a quand même un bagage très honorable en C. Pour écrire un pilote noyau il n'y a pas besoin de beaucoup plus. Comme il le dit lui même, cela démystifie le noyau en un sens, le noyau n'est pas aussi mystique qu'un autre projet. Écrire un pilote noyau basique est limite plus simple que de contribuer à de nombreux projets qui ont l'air plus simple en apparence en espace utilisateur. Peut être que s'il avait fait tout tout seul cela ne lui aurait pas pris tant de temps que cela en plus avec des connaissances en C suffisante.
Je suis également étonné qu'il dise que faire cela lui aurait surtout nécessité de comprendre du code ancien et inutile. Il a peut être en partie raison, mais de l'autre il aurait malgré tout eu besoin de lire ou écrire du code noyau moderne ce qui est pour le coup plus utile. D'ailleurs il semble dire qu'il fera du code noyau récent à l'avenir donc ce n'est pas si inutile de se plonger dans ce genre d'exercices à mon sens car le volet moderne du code reste valorisable.
J'aime bien en tout cas la problématique de base que je trouve intéressante.
# j'ai demander a l'auteur
Posté par ChocolatineFlying . Évalué à 2 (+2/-1).
des précisions sur le code modifié si il est possible de voir facilement les diff :
Thanks for getting in touch!
You are welcome to look through the git history of the repository: https://github.com/dbrant/ftape
The specific commits that benefited most from Claude Code are probably these three:
https://github.com/dbrant/ftape/commit/40011370fe0a202c162cada529e27c8556365e96
https://github.com/dbrant/ftape/commit/acaf1244ae3c2909bedc39bc122b9581b54c5581
https://github.com/dbrant/ftape/commit/eb24f8bf13e5ea42a360e69ea780187aa7cbf491
Unfortunately I accidentally committed a bunch of unnecessary metadata files (.cmd and .symvers), which makes the commits look a bit messy. It's really just the changes to .c files and makefiles that are relevant.
Best,
[^] # Re: j'ai demander a l'auteur
Posté par Cyrille Pontvieux (site web personnel, Mastodon) . Évalué à 2 (+0/-0). Dernière modification le 11 septembre 2025 à 21:45.
Bon c’est rébarbatif mais c’est pas fou fou non plus (si on ne regarde que les fichiers .c ou .h)
Par contre c’est vrai que le vieux code est dur à lire parce que c’est du code C dégueu (rien à voir avec le fait que c’est vieux je pense)
C’est quand même pas évident de comprendre ce que ça fait. Je savais même pas qu’on pouvait faire cette syntaxe en C !
Ça veut dire incrémente le pointer
ptrde la taille d’un entier non signé 32 bits si je ne me trompe pas.Le LLM a proposé
Qui se lit quand même franchement mieux, même pour quelqu’un qui fait pas du C tous les jours…
Alors est-ce que
sizeofn’a été disponible dans les compilo que tardivement ?[^] # Re: j'ai demander a l'auteur
Posté par Pol' uX (site web personnel) . Évalué à 4 (+2/-0).
Je n'ai pas fait de C depuis 20 ans mais je reconnais un cast. Rien de franchement exotique…
Adhérer à l'April, ça vous tente ?
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.