Excuse-moi pour le message précédent, je vais la refaire plus calme :
Ah non non. On parle interface de driver. Et ce que justement je dénonce c'est cette volonté de vouloir "fermé" le noyau en déclarant "c'est de la tambouille interne".
La volonté des développeurs du noyau n'est pas de "fermer" son développement en préférant intégrer les drivers dans la branche principale, mais de prévenir les développeurs externes qu'ils vont devoir s'adapter régulièrement à des petits changements s'ils décident de rester en dehors. Comme ça, ils sont prévenus et n'ont pas à gueuler après, que c'est comme ça que ça se passe quand on fait du dev sur le kernel. Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Pour moi l'interface des drivers du noyau constitue pleinement une interface utilisateur. Tout du moins ca devrait l'être.
Là, tu demandes à redéfinir les bases de notre discussion : jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur. Mais donc ce que tu proposes aujourd'hui c'est de standardiser l'interface driver ? Ca demande un autre débat ...
Ah bah oui, un code de qualité, c'est sûr, ca demande plus d'effort, que voulez vous ma petite dame, on peut pas tout avoir, la liberté et la qualité. Moi je dénonce au passage que ce manque de qualité est à mettre en corrélation avec un mode de développement fermé, ce que je trouve vraiment dommage dans le monde des logiciels libres.
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
T'as déjà développé en groupe ou quoi ? Entre faire 15 passes successives sur un même code pour acoucher d'un truc bancal et une réécriture propre tu trouves que c'est où la perte de temps ?
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ? Le changement sera d'autant plus grand ! Des changements petit à petit ça permet justement de pas trop perdre de drivers d'un coup, de faire la transition "doucement" (même si ça casse à chaque fois, les modifications sont mineures). Arriver à une bonne API du premier coup est quasi impossible, c'est pour ça que le code n'est jamais vraiment réécrit "from scratch" quand on propose une nouvelle API. Et ce n'est pas parce que ce n'est pas refait complètement que c'est bancal ! Franchement, regarde les sources du noyau, ya des fichiers qui ont encore l'entête de linux avant la 1.0, et pourtant ils sont aujourd'hui, après modifications successives, très bien intégrés à l'ensemble.
Ca c'est effectivement la situation actuelle. Moi je râle sur ces changements incessant. Evidemment qu'il ne faut pas rester avec des API "figés". Que y'es des gros changement de Linux 2.4 à 2.6, je comprend. Qu'il y en ai tous les mois voir toutes les semaines, ca devient hallucinant. Les API qui "cassent" la compatibilité avec l'existant devrait apparaître dans les versions majeures, tous les 2 ans (je donne l'ordre de grandeur).
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ? (c'est pas pour te faire chier à montrer que j'ai raison ou que t'en trouves pas, c'est vraiment pour étudier le problème plus concrètement) Des changements d'ABI incessants, peut-être, et c'est normal, pour l'API par contre ... à moins que tu ne parles d'une section encore expérimentale ou en cours de développement ?
Mouarf, arrête de parler du problème du proprio. Enlève du sujet le proprio tu veux bien. Moi tu vois lors de l'intégration du pilote libre Gatos dans X.org (gestion des tuner et I/O video des cartes Radeon AIW), j'ai tout simplement vu disparaître un grand nombre de fonctionnalité de ma carte graphique. Youplaboum. Je fais quoi : je reste avec l'ancienne version ? Je maintiens moi même dans mon coin un driver que je dois modifier à chaque fois que les API changent ? Merci bien. C'est pas un problème de proprio/libre, c'est un problème général. Et j'en ai marre d'entendre cette excuse à 2 francs, limite on casse les API exprès pour faire chier le proprio. Et c'est la même chose à chaque fois : "pourquoi vous cassez les API ?" "Proprio c mal toussa". Où comment chercher des excuses philosophiques à des problèmes techniques. Du grand n'importe quoi (:-p)
Pour ton problème spécifique, ça me paraît dommage en effet, c'est peut-être le manque de détermination du dev qui a fait que peu de personnes se sont intéressées à l'intégration... alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes (selon moi, je ne connais pas vraiment grand monde qui a une AIW), il faut arriver à convaincre les devs upstream que son problème est important. C'est toujours pareil, on est pas dans une entreprise, on est dans un projet communautaire ... Bon, ça doit pas devenir une excuse, effectivement pour ce cas là il y a effectivement un problème, mais ce n'est pas un problème d'API selon moi (sinon je veux bien quelques liens pour mieux comprendre).
Pour le coup des devs qui changent l'API rien que pour faire chier les devs proprio, je te laisse dans ta parano, ce n'est pas du tout ce que j'ai dit.
Pour moi un API qui change tout le temps, ca revient à faire une API fermée. La documentation n'est pas le saint graal. "Ah j'ai documenté, demerdez vous !".
Je comprend ce que tu veux dire par là, mais je ne serais pas aussi extrême : oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
Arrête avec ton "n'importe quoi". Tu fais exprès de pas comprendre. Je voulais dire qu'une des seules normes que le noyau suit, c'est l'interface POSIX, imposée dans un monde proprio. Ils avaient des bonnes pratiques à l'époque, il n'y a pas de raison de ne pas les utiliser aujourd'hui dans le monde libre. C'est pour ca que j'ironisait au début en disant qu'il faudrait standardiser les API de drivers du noyau, histoire de.
Alors moi aussi je vais dire que tu fais exprès de ne pas comprendre : POSIX désigne une interface utilisateur, ce qui n'a rien à voir avec une interface driver. On aura toujours une API permettant d'ouvrir un fichier avec une fonction, de lire tant d'octets avec une autre, etc ... Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter. Et même les anciennes suivent le pas.
Houlà, mais je suis pas intolérant, je respecte le choix des développeurs du noyau, je serais inccapable de faire ce qu'ils font, mais en tant qu'utilisateur je donne mon avis. Enfin si on me pertinente, c'est que certains sont peut être dans la même situation que moi, à savoir de simple utilisateur qui aimerait voir leur noyau plus stable.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes (je n'ai pas dit que tu n'avais pas le droit de donner ton avis par contre, soyons clairs). Cela devrait être réglé par les devs. Je trouve ça dommage par contre si certains utilisent leur communauté d'utilisateur comme moyen de chantage sur d'autres devs.
C'est vrai que quand on prend un tout petit bout d'une phrase, en virant le contexte, en faisant samblant de pas comprendre ce que le type a voulu dire, et en disant "n'importe quoi" toutes les 2 lignes, ont doit vite s'énerver.
J'ai cité l'intégralité de ton commentaire, en analysant phrase par phrase, et en m'efforçant de comprendre quand ce n'était pas des critiques lancées gratuitement en l'air.
Un truc aussi qui m'énerve dans cette situation : Linux s'impose comme impossible à forker. J'entend par là que c'est pas demain la veille qu'on aura une alternative à Linux. Pas d'API stables pour les drivers ? Pas de couche d'abstraction du fonctionnement sous-jacent. Et donc pas d'alternative possible au coeur du noyau sans un fork de l'ensemble des drivers. Moi j'aimerai bien avoir une banque de driver "réutilisable" avec des vrais alternatives quand au noyau utilisé dessous.
Oui, dans l'idéal, ce serait comme ça qu'il faudrait faire. Mais trouve moi quelqu'un qui arrive du premier coup à rassembler toutes ces qualités dans son code. Il n'existe aujourd'hui aucun OS capable de cela sans un minimum de changement de code et de cassage d'API.
Je pense que tout le problème, c'est de décider entre avoir un truc très stable mais sur lequel il faudra bidouiller au cas où on a pas visé juste du premier coup, ou alors faire un truc qui évolue tout le temps, mais qui casse régulièrements les APIs. La solution choisie pour linux est la 2e, et la philosophie du développement kernel, ça a toujours été d'effectuer les changements petit à petit, sans trop gros accoups. Au final, cela permet d'évoluer plus vite, et la modularisation arrive petit à petit; un jour, on verra peut-être une interface stable aux drivers, quand le kernel aura bien été séparé et "standardisé". Par exemple, la possibilité d'utiliser une machine sans MMU (changement assez profond, quand même), n'a été intégrée qu'au 2.6, alors qu'il existait des patches depuis quelques temps pour le 2.4, mais il a fallu la volonté des devs et leur persévérance pour changer petit à petit le code du noyau, jusqu'à être intégrés upstream.
[^] # Re: Faut pas exagerer...
Posté par benoar . En réponse à la dépêche Une plongée dans le développement de Linux. Évalué à 5.
La volonté des développeurs du noyau n'est pas de "fermer" son développement en préférant intégrer les drivers dans la branche principale, mais de prévenir les développeurs externes qu'ils vont devoir s'adapter régulièrement à des petits changements s'ils décident de rester en dehors. Comme ça, ils sont prévenus et n'ont pas à gueuler après, que c'est comme ça que ça se passe quand on fait du dev sur le kernel. Tu va me dire que ça donne le même résultat au final : soit on se fait intégrer upstream, soit on est condamné à rester à la bourre; mais sinon, ce serait le kernel qui serait tout le temps à la bourre.
Là, tu demandes à redéfinir les bases de notre discussion : jusqu'à maintenant, l'interface des drivers n'est pas une interface utilisateur car justement tout se passe en espace kernel, pas utilisateur. Mais donc ce que tu proposes aujourd'hui c'est de standardiser l'interface driver ? Ca demande un autre débat ...
Quel rapport entre maintenir une API stable et la qualité du code ? Linux est très bien codé même si son API est changeante.
D'un côté tu reproches l'API trop changeante, et après tu souhaites une réécriture complète (en parallèle avec l'ancienne, je suppose) ? Le changement sera d'autant plus grand ! Des changements petit à petit ça permet justement de pas trop perdre de drivers d'un coup, de faire la transition "doucement" (même si ça casse à chaque fois, les modifications sont mineures). Arriver à une bonne API du premier coup est quasi impossible, c'est pour ça que le code n'est jamais vraiment réécrit "from scratch" quand on propose une nouvelle API. Et ce n'est pas parce que ce n'est pas refait complètement que c'est bancal ! Franchement, regarde les sources du noyau, ya des fichiers qui ont encore l'entête de linux avant la 1.0, et pourtant ils sont aujourd'hui, après modifications successives, très bien intégrés à l'ensemble.
Bon, depuis le début, tu parles de changements incessants : aurais-tu un exemple ? (c'est pas pour te faire chier à montrer que j'ai raison ou que t'en trouves pas, c'est vraiment pour étudier le problème plus concrètement) Des changements d'ABI incessants, peut-être, et c'est normal, pour l'API par contre ... à moins que tu ne parles d'une section encore expérimentale ou en cours de développement ?
Pour ton problème spécifique, ça me paraît dommage en effet, c'est peut-être le manque de détermination du dev qui a fait que peu de personnes se sont intéressées à l'intégration... alors oui c'est encore un autre problème, surtout quand on est sur un problème qui concerne peu de personnes (selon moi, je ne connais pas vraiment grand monde qui a une AIW), il faut arriver à convaincre les devs upstream que son problème est important. C'est toujours pareil, on est pas dans une entreprise, on est dans un projet communautaire ... Bon, ça doit pas devenir une excuse, effectivement pour ce cas là il y a effectivement un problème, mais ce n'est pas un problème d'API selon moi (sinon je veux bien quelques liens pour mieux comprendre).
Pour le coup des devs qui changent l'API rien que pour faire chier les devs proprio, je te laisse dans ta parano, ce n'est pas du tout ce que j'ai dit.
Je comprend ce que tu veux dire par là, mais je ne serais pas aussi extrême : oui ça prend pas mal de temps de s'adapter, mais ce n'est pas du dev "fermé".
Alors moi aussi je vais dire que tu fais exprès de ne pas comprendre : POSIX désigne une interface utilisateur, ce qui n'a rien à voir avec une interface driver. On aura toujours une API permettant d'ouvrir un fichier avec une fonction, de lire tant d'octets avec une autre, etc ... Par contre, pour le matériel, les nouveaux bus, les nouvelles technologies, etc ... arrivent régulièrement, et il faut s'adapter. Et même les anciennes suivent le pas.
Le problème, à mon avis, en tant que simple utilisateur, c'est que tu n'as pas à t'occuper de ces problèmes (je n'ai pas dit que tu n'avais pas le droit de donner ton avis par contre, soyons clairs). Cela devrait être réglé par les devs. Je trouve ça dommage par contre si certains utilisent leur communauté d'utilisateur comme moyen de chantage sur d'autres devs.
J'ai cité l'intégralité de ton commentaire, en analysant phrase par phrase, et en m'efforçant de comprendre quand ce n'était pas des critiques lancées gratuitement en l'air.
Oui, dans l'idéal, ce serait comme ça qu'il faudrait faire. Mais trouve moi quelqu'un qui arrive du premier coup à rassembler toutes ces qualités dans son code. Il n'existe aujourd'hui aucun OS capable de cela sans un minimum de changement de code et de cassage d'API.
Je pense que tout le problème, c'est de décider entre avoir un truc très stable mais sur lequel il faudra bidouiller au cas où on a pas visé juste du premier coup, ou alors faire un truc qui évolue tout le temps, mais qui casse régulièrements les APIs. La solution choisie pour linux est la 2e, et la philosophie du développement kernel, ça a toujours été d'effectuer les changements petit à petit, sans trop gros accoups. Au final, cela permet d'évoluer plus vite, et la modularisation arrive petit à petit; un jour, on verra peut-être une interface stable aux drivers, quand le kernel aura bien été séparé et "standardisé". Par exemple, la possibilité d'utiliser une machine sans MMU (changement assez profond, quand même), n'a été intégrée qu'au 2.6, alors qu'il existait des patches depuis quelques temps pour le 2.4, mais il a fallu la volonté des devs et leur persévérance pour changer petit à petit le code du noyau, jusqu'à être intégrés upstream.