On dirait qu’une fronde contre les modules proprio vient d’éclater sur la LKML
A l’origine, un patch de Greg KH qui permettrait d’implémenter plus facilement des pilotes d’entrée sortie en espace utilisateur (“userspace io driver interface added”). S’en suit un belle réponse de Linus puisque dans le patch, y a un code qui ferait sortir des IRQ handler de l’espace noyau (“Ok, what kind of ass-hat idiotic thing is this ?”). Micheal K. Edwards supplie Linus de ne pas laisser Greg de faire ça ("Embedded systems integrators have enough trouble with chip vendors who think that exposing the device registers to userspace constitutes a driver. "). Réponse de Greg : c’est à cause de ça qu’ils font des pilotes binaires qui foutent la merde. Martin Bligh propose donc d’accepter ce système tout en bloquant toute possibilité de charger des modules binaires.
Si quelqu’un a une meilleure traduction, merci de nous la faire partager.
En tout cas, je pense que ça va donner des sueurs froides à certains fabriquants de prériph (de CG en particulier)
je pige pas pourquoi les boites comme nvidia, ati, creative, etc… mettent pas des devs sur linux pour COLLABORER avec les dev du noyau et améliorer le fonctionnement actuel…
linux est faussement GPL, puisque réalistement il est impossible de bien faire tourner un système open source récent sans driver proprio
mais l’entetement et le franc parler de linus thorvald sont légendaire
D’un cote je me dis “ouais ! virons les drivers proprio ! c’est de la merde ! faut nettoyer !” et d’un autre cote je me dis que linux aura du mal a progresser plus meme professionnellement si on met pas un peu d’eau dans notre vin…
D’un cote je me dis qu’on a pas besoin de technos proprio puisqu’on a aussi bien voire mieux en libre dans beaucoup de cas mais d’un autre cote il est impossible que des pro ou meme des particuliers acceptent de toucher linux si il n’y a pas une certaine compatibilite…
Et l’Histoire nous a toujours montre qu’il y a extremement rarement de passage en masse d’un techno a l’autre sans une certaine possibilite de migrer en douceur.
En fait, j’en viens de plus en plus a penser que si on accepte qq drivers proprios dans le noyau, ca va pas motiver les autres constructeurs a rendre leur drivers proprio mais plutot simplifier la vie de tout le monde dans un premier temps puis ca va surement apprivoiser les constructeurs un peu retifs et les pousser a liberer leur sources pour beneficier du concours de la communaute.
Si on exclut les constructeurs qui souhaitent faire des drivers linux mais sans liberer le code, non seulement on va entretenir une image d’“integristes” mais aussi favoriser les mythes et les legendes debiles au sujet du Libre aupres de constructeurs qui ne pourront pas savoir comment ca marche de l’interieur puisqu’ils sont exclus.
Comment aider une migration si le seul moyen de tester est de faire le grand saut sans possibilite de retour ?
en meme temps, les drivers qui foutent la zone sont généralement des drivers bureautique (webcam, carte graphique, raid de carte mére, carte son, etc…)
et franchement pour un système serveur, on s’en tamponne le coquillard de ca ! alors que les drivers proprio restent en dehors, ca ne géne que les particuliers… et encore
Un des problèmes du nouveau mode de développement du noyau réside dans les nombreuses modifications des API.
Quand on développe un driver qui n’est pas (encore?) inclus dans le noyau, c’est très biiiiiiiip. Qu’il soit GPL ou pas.
Par exemple, les ATI ne compilent plus à chaque nouvelle version du noyau mais les modifications à faire sont souvent triviales et bien souvent (depuis au moins 10 version du noyau) dans la partie dont on a les sources…
et pourquoi ca devrait etre aux devs de faire l’effort ? ATI et NVIDIA et tous les autres pourrait s’impliquer dans le dev du noyau pour y inclure un peu mieux leurs drivers…et en gpl surtout !
Simplement parce que certains develo de certains drivers GPL qui ne sont pas inclus dans le noyau en ont un peu marre de passer du temps à modifier leur code à cause de ces changements d’API.
Je pense ici à l’API V4L2 qui est aussi stable qu’un éléphant sur patin à glace;
Je passe aussi du temps à chaque nouveau noyau pour faire fonctionner les ATI à nouveau (en patchant…la partie dont on a les sourcces).
Bref ces chagements d’APPI sont parfois une perte de temps pour un gain faible, GPL ou pas.
+1, surtout quand on voit que les pilotes libres graphiques pour les cartes ati ont bientôt rattrappé les proprio ati :paf: Et niveau fonctionnalités, les libres sont plus complets.
Et généralement, les pilotes GPL qui sont pas dans le noyau (et qui existent depuis suffisamment longtemps pour que leur dev en ait « un peu marre de passer du temps à modifier leur code ») c’est pas parce que c’est un peu pourrite comme driver ?
Sufflope : Merci Bon quand qlqn prend le temps de développer un driver qui sera inclus dans le noyau des mois après, c’est de la daube! héhé. Autre objection : Une fois que le driver est dans le noyau, on veut souvent avoir en parallèle une branche que dével qui intègre plus de nouveautés “instables” que la version dans le noyau. Dans ce cas, tu te retrouve donc à avoir un driver hors noyau à maintenir.
De plus, les changements d’API sont tout autant biiiip les dévelo de drivers dans le noyau qu’en dehors. Vous pensez que ça fait marrer les gens de passer du temps à changer kmalloc et memset(…0) en kzalloc ou if(test) BUG_ON() en BUG_ON(test)? non. Pas moi en tout cas :(.
ATI et NVIDIA ont un marché immense mais imaginer une petite entreprise qui fabrique un périphérique:
“Faisons nous un driver Linux?”
“Arf vu le temps passer à adapter les API, on laisse tomber et si vraiment on voit qu’il y a un marché, on s’y mettera mais avec un support léger”.
Fiction?? Peut être pas
Bon quand qlqn prend le temps de développer un driver qui sera inclus dans le noyau des mois après, c’est de la daube! héhé. Autre objection : Une fois que le driver est dans le noyau, on veut souvent avoir en parallèle une branche que dével qui intègre plus de nouveautés “instables” que la version dans le noyau. Dans ce cas, tu te retrouve donc à avoir un driver hors noyau à maintenir.