2 jours non, je suis sensé le finir 6 mois avant aussi ? A chaque update je dois attendre 6 mois ? Sur des projets dont le cycle est de moins de 6 mois, on va dire que c'est pas top.
6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.
Par contre, si tu es dans le kernel, non, tu n'as pas à attendre 6 mois pour chaque update; une fois le driver inclus, les itérations sont beaucoup plus rapides.
Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau. C'est particulièrement vrai pour la plupart des périphériques d'acquisition de données ou de contrôle. Dès que tu peux passer par l'USB et que tu n'as pas à contourner le contrôleur standard de Linux pour gérer les bugs de ton périphérique, alors ton driver peut tout à fait résider en espace utilisateur (privilégié) et utiliser l'API/ABI USB standard et stable pour communiquer avec le périphérique.
Je donne un exemple, je ne dis pas que c'est le plus pertinent, mais c'est le premier qui me vient en tête vu mon occupation actuelle : Phidgets, qui est une boîte dont le coeur de métier est la commercialisation de senseurs et contrôleurs faciles à interfacer (autant au niveau hardware que software). Leur driver est une simple librairie qui supporte C/C++, C#, Python, Java, VB.NET, etc. et qui est binairement compatible avec pour ainsi dire toutes les distributions (en autant que libusb soit installé, ce qui est un prérequis acceptable je crois).
Et ça tombe très bien pour eux : effectivement, lorsqu'ils sortent un nouveau produit (par exemple un nouveau thermocouple), ils n'ont pas envie d'attendre plusieurs mois pour qu'il soit pris en charge par les systèmes Linux, mais il leur suffit de mettre à jour leur librairie et ça marche automatiquement partout.
Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.
Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.
[^] # Re: Tu peu même élargir ...
Posté par Kalenx . En réponse au journal C'est lundi : Mon expérience Linux ou l'utopie devient réalité extatique. Évalué à 5.
6 mois, c'est effectivement trop long dans la plupart des cas (même si il y en a certains à qui ça convient, comme par exemple Intel). Ceci étant, je n'ai aucune statistique sur le délai moyen entre un premier pull request dans stagging et une inclusion dans le mainline.
Par contre, si tu es dans le kernel, non, tu n'as pas à attendre 6 mois pour chaque update; une fois le driver inclus, les itérations sont beaucoup plus rapides.
Par ailleurs, je réitère : beaucoup de périphériques n'ont pas à avoir un driver en espace noyau. C'est particulièrement vrai pour la plupart des périphériques d'acquisition de données ou de contrôle. Dès que tu peux passer par l'USB et que tu n'as pas à contourner le contrôleur standard de Linux pour gérer les bugs de ton périphérique, alors ton driver peut tout à fait résider en espace utilisateur (privilégié) et utiliser l'API/ABI USB standard et stable pour communiquer avec le périphérique.
Je donne un exemple, je ne dis pas que c'est le plus pertinent, mais c'est le premier qui me vient en tête vu mon occupation actuelle : Phidgets, qui est une boîte dont le coeur de métier est la commercialisation de senseurs et contrôleurs faciles à interfacer (autant au niveau hardware que software). Leur driver est une simple librairie qui supporte C/C++, C#, Python, Java, VB.NET, etc. et qui est binairement compatible avec pour ainsi dire toutes les distributions (en autant que libusb soit installé, ce qui est un prérequis acceptable je crois).
Et ça tombe très bien pour eux : effectivement, lorsqu'ils sortent un nouveau produit (par exemple un nouveau thermocouple), ils n'ont pas envie d'attendre plusieurs mois pour qu'il soit pris en charge par les systèmes Linux, mais il leur suffit de mettre à jour leur librairie et ça marche automatiquement partout.
Je ne dis pas que tout le monde peut faire ça, mais pour la plupart des boites dont l'écriture de drivers n'est pas le coeur de métier (par exemple des compagnies qui veulent commercialiser un nouveau produit dont le driver n'est qu'une interface, l'innovation étant vraiment dans le produit en soi), il n'y a aucun problème avec le modèle actuel.
Pour les boites plus grosses, pour qui les drivers représentent en soi un atout important, oui, j'espère que ceux-ci sont terminés 3 mois avant la sortie du produit qu'ils accompagnent, et que les développeurs sont passés à l'écriture du driver de la génération suivante.