Un pilote (binaire ou non) s'execute dans l'espace kernel et a donc acces a tout [..] La confiance dans le fournisseur de ce pilotes est donc necessaire.
Kernel mal conçu. Beaucoup de pilotes n'ont aucun intérêt à tourner avec les privilèges du kernel et pourrait très bien fonctionner en mode utilisateur. Bref, le vrai problème est ailleur pour ce qui est de la "confiance". Et c'est valable également pour un driver Open-source, on peut faire confiance au fait qu'il ne contient pas de code malicieux, mais on est jamais à l'abris d'une erreur de programmation qui fait tout péter.
si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
(Avec un driver open source, la source ne se compilerait plus, si des modifs devait etre faites pour le passage du 32 au 64 elle pourrait ce faire, le support d'un driver open source et faisable, binaire non).
Dans la vraie vie, le code source n'est pas la solution miracle : si le matos n'est pas beaucoup utilisé, personne n'ira maintenir le driver. J'en ai fait l'amer expérience sous Linux avec les drivers Gatos pour ma radeon AIW (pas du matos confidentiel hein), qui reviennent castrés dans le dernier XOrg sans acquisition video. Des sources ne servent à rien pour l'utilisateur lambda qui se trouve seul face à son problème.
S'il y avait un minimum de péreinité des interfaces binaires, on aurait moins de problèmes.
Les sources assurent une meilleure péreinité, une meilleure portabilité (32/64 bits par exemple), mais ca n'est pas non plus une garantie qui remplace une stabilité des API. Parfois c'est une simple illusion.
Plutôt que de s'amuser à maintenir des milliers de drivers dans un même bouzin (pas le choix, c'est monolithique et les interfaces bougent en permanence), ils feraient mieux de s'atteler à stabiliser les API, proposer des nouvelles API et continuer à supporter binairement les anciennes. C'est du boulot, mais c'est sûrement pas pire que maintenir des milliers de drivers. Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
Si en plus ca pouvait faire réfléchir à l'architecture du kernel (stabilité des API, privilèges du code exécuté)
Et oui, ca laisserait la porte ouverte aux pilotes binaires, mais c'est quoi le problème ? Au pire on a du matos supplémentaire qui fonctionne sous Linux sans alternative libre, au mieux ca fait double emploi avec un driver libre. C'est où le problème ?
Enfin si le kernel ne veut pas bouger, heuresement des acteurs plus pragmatiques commencent à se bouger le cul (style Dell : http://linux.dell.com/projects.shtml ) ou des petits projets comme FUSE ( http://fuse.sourceforge.net/ ). Dommage d'en arriver à des abérations où on est obligé de créer des couches de glue supplémentaire pour palier des manques de conception sous-jacent.
Ah oui dernier point : stabiliser les API favoriserait l'apparition de drivers alternatifs maintenus par d'autres personnes que les developpeurs du kernel, voir des kernels alternatifs qui profiterait de l'API stable pour supporter un grand nombre de drivers.
[^] # Re: Confiance et pérénité
Posté par TImaniac (site web personnel) . En réponse au journal Marre de l'intégrisme chez les libristes !!!. Évalué à 2.
Kernel mal conçu. Beaucoup de pilotes n'ont aucun intérêt à tourner avec les privilèges du kernel et pourrait très bien fonctionner en mode utilisateur. Bref, le vrai problème est ailleur pour ce qui est de la "confiance". Et c'est valable également pour un driver Open-source, on peut faire confiance au fait qu'il ne contient pas de code malicieux, mais on est jamais à l'abris d'une erreur de programmation qui fait tout péter.
si tu change de kernel pour une meuilleur gestion du SATA (par exemple) ton pilote binaire ne voudra plus se charger
Là encore, le problème vient d'une absence de stabilité des API du kernel. Le problème est là encore une mauvaise architecture des interfaces du kernel.
le pire c'est que sous windows ces memes fabricant ne propose pas de drivers Vista pour du materiel qui as a peine 2 ou trois ans, les gens sont obligés de changer du materiel fonctionnel contre un autre.
Même si ce n'est pas toujours vrai, beaucoup de drivers binaires pour Windows XP (voir Win2000) fonctionne toujours sous Vista. Signe qu'il est possible d'avoir une certaine pereinité dans le temps, même entre 2 versions majeures d'un OS.
(Avec un driver open source, la source ne se compilerait plus, si des modifs devait etre faites pour le passage du 32 au 64 elle pourrait ce faire, le support d'un driver open source et faisable, binaire non).
Dans la vraie vie, le code source n'est pas la solution miracle : si le matos n'est pas beaucoup utilisé, personne n'ira maintenir le driver. J'en ai fait l'amer expérience sous Linux avec les drivers Gatos pour ma radeon AIW (pas du matos confidentiel hein), qui reviennent castrés dans le dernier XOrg sans acquisition video. Des sources ne servent à rien pour l'utilisateur lambda qui se trouve seul face à son problème.
S'il y avait un minimum de péreinité des interfaces binaires, on aurait moins de problèmes.
Les sources assurent une meilleure péreinité, une meilleure portabilité (32/64 bits par exemple), mais ca n'est pas non plus une garantie qui remplace une stabilité des API. Parfois c'est une simple illusion.
Plutôt que de s'amuser à maintenir des milliers de drivers dans un même bouzin (pas le choix, c'est monolithique et les interfaces bougent en permanence), ils feraient mieux de s'atteler à stabiliser les API, proposer des nouvelles API et continuer à supporter binairement les anciennes. C'est du boulot, mais c'est sûrement pas pire que maintenir des milliers de drivers. Ca laisserait les gens les plus compétents (souvent les constructeurs) gérer le cycle de vie de leurs drivers, qui ne devrait pas être imposer selon les bons vouloir de Linus & Co.
Si en plus ca pouvait faire réfléchir à l'architecture du kernel (stabilité des API, privilèges du code exécuté)
Et oui, ca laisserait la porte ouverte aux pilotes binaires, mais c'est quoi le problème ? Au pire on a du matos supplémentaire qui fonctionne sous Linux sans alternative libre, au mieux ca fait double emploi avec un driver libre. C'est où le problème ?
Enfin si le kernel ne veut pas bouger, heuresement des acteurs plus pragmatiques commencent à se bouger le cul (style Dell : http://linux.dell.com/projects.shtml ) ou des petits projets comme FUSE ( http://fuse.sourceforge.net/ ). Dommage d'en arriver à des abérations où on est obligé de créer des couches de glue supplémentaire pour palier des manques de conception sous-jacent.
Ah oui dernier point : stabiliser les API favoriserait l'apparition de drivers alternatifs maintenus par d'autres personnes que les developpeurs du kernel, voir des kernels alternatifs qui profiterait de l'API stable pour supporter un grand nombre de drivers.