Vous en aviez rêvé ? SUSE l'a peut-être fait : il est désormais de nouveau possible de développer des drivers externes au noyau tout en assurant la compatibilité quelque-soit la version mineure de ce noyau :
SUSE SolidDriver
Bien entendu, ceci n'est applicable que pour la gamme SUSE Linux Enterprise (pas OpenSUSE ni d'autres distributions). En gros, un constructeur OEM (HP est cité dans le lien ci-dessus) pourra désormais développer un driver pour du nouveau matériel, en s'appuyant sur l'API SUSE, permettant ainsi de limiter les risques d'incompatibilité avec la distribution.
Théoriquement, cela devrait permettre d'assurer la compatibilité pour les différents services packs de la distribution.
Bientôt un concept universel ?
Beaucoup de constructeurs rêvent de pouvoir développer un driver qui reste compatible quelque soit la version mineure du noyau. Nvidia a plus ou moins réussi son pari (X.org et versions mineures du noyau). Mais il n'est pas évident pour un constructeur qui ne souhaite pas dévoiler son code source pour des raisons de propriété intellectuelle de maintenir un driver à l'extérieur du développement du kernel.
Exemple : un constructeur comme Epson qui sort un matériel pourrait théoriquement développer un driver pour les principales distributions du marché. Cependant, tout patch du noyau casserait la compatibilité et le matériel deviendrait inutilisable. Deux solutions s'offrent au constructeur :
- Maintenir le driver via un repository dédié à la distribution (ATI, Nvidia le font)
- Donner le code source (mais attention aux problèmes de propriété intellectuelle)
Obtenir une API stable pour une version majeure donnée pourrait permettre à ces constructeurs de développer un driver efficace pour leur matériel. Un exemple (qui n'est pas forcément à suivre) serait de prendre Windows 8 : Un driver développé pour Windows 8 fonctionne (à 99% des cas) sur Windows 8.1. Si Microsoft n'avait pas développé une API stable, cela aurait causé de multiples retards ou entrainé une forte mobilisation des constructeurs pour redévelopper leur driver (sans compter qu'un patch Windows ne casse pas la compatibilité des drivers installés, qui ne sont pas touts OpenSource).
Comme quoi, il faut savoir prendre le meilleur des deux mondes…
# ça marche comment?
Posté par ʭ ☯ . Évalué à 5.
Linus refuse de fixer l'API Linux, donc comment fonctionne la surcouche SUSE? Ça peut pas marcher bien longtemps, à moins que la version mineure soit le z de x.y.z, qui n'a jamais de changements d'API, donc la surcouche est
inutilemarketing.⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: ça marche comment?
Posté par Krunch (site web personnel) . Évalué à 10.
C'est décrit par là http://drivers.suse.com/doc/SolidDriver/How_It_Works.html#how-it-works
Apparement c'est fort similaire à ce qui se fait dans RHEL. L'idée c'est que l'organisation qui maintient la distribution garantit la « stabilité » de certains symboles. Évidemment, ça marche qu'avec un kernel que l'organisation contrôle et tu vas pas pouvoir magiquement installer le dernier linux-next de kernel.org sans tout péter.
Après, au moins dans RHEL, il y a des mécanismes intégrés à rpmbuild pour éviter que les gens ne dépendent par erreur de symboles dont la stabilité n'est pas garantie. En pratique, les symboles dont la stabilité est garantie sont groupés en kABIs (genre tous les trucs liés au réseau,…) pour lesquels une signature est générée. Le kernel satisfait donc des dépendances telles que "kernel(rhel5_net_sunrpc_ga) = 24164573208ac3a8706912194cb786857d2222d6". Quand tu buildes un modules pour ce kernel, rpmbuild va examiner tous les symboles dont il dépend et les ajouter en dépendances au niveau RPM, soit via les kABIs explicités (et du coup ça marche pour tous les kernels dont la signature du kABI correspondant ne change pas), soit en explicitant le dépendance sur le symbole spécifique et sa signature s'il ne fait pas partie d'un kABI « supporté » (et du coup, le RPM du module va pas s'installer parce que la dépendance est pas satisfaisable puisque le RPM du kernel ne la satisfait pas explicitement).
Pour RHEL5 c'est détaillé (sans doute plus clairement que mon pavé ci-dessus) dans http://driverupdateprogram.com/presentations/DriverUpdateProgramTechnical.pdf
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ça marche comment?
Posté par ʭ ☯ . Évalué à 2.
Ok, merci, donc ça revient bien à proposer un paquet par version de RHEL pour le constructeur. Et puis
zuttroll, rien à gagner pour ceux qui aiment le libre.⚓ À g'Auch TOUTE! http://afdgauch.online.fr
[^] # Re: ça marche comment?
Posté par Krunch (site web personnel) . Évalué à 3.
Pour chaque version majeure qui est supportée « longtemps » (de l'ordre de 10 ans pour RHEL IIRC). Il peut y avoir des changement de kABI entre versions mineures mais ils essaient de s'arranger pour que ça n'arrive pas et je suppose qu'ils se coordonnent avec les « partenaires » qui fournissent des drivers.
C'est vrai qu'en dehors de la distribution elle-même, ça ne change rien. Enfin, le mécanisme peut être réutiliser par d'autres distros si elles le souhaitent (sans doute sans avoir à rien coder si elles utilisent déjà RPM).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ça marche comment?
Posté par Zenitram (site web personnel) . Évalué à 1.
Bien sûr que si : des utilisateurs, et donc une meilleure prise en considération, et donc des développeurs, dont une part de libre, ce qui est largement mieux que rien.
ah… Avec des libristes comme ça, pas besoin d'ennemis!
(je sais, tu as parlé de troll, je tombe dedans)
[^] # Re: ça marche comment?
Posté par Zenitram (site web personnel) . Évalué à 1.
Mais est-ce compatible ou similaire?
Parce que c'est mieux qu'aujourd'hui, mais si un développeur doit encore se taper 1 API par distro Linux, c'est lourd (bon, après, dans le monde pro qui pense long terme, c'est RHEL ou SuSE sur les serveurs, alors ça va pas faire trop de différentes API)
# chez Red Hat Enterprise Linux aussi
Posté par Krunch (site web personnel) . Évalué à 6.
Ils ont ça chez RHEL aussi et ça s'appelle Red Hat Enterprise Linux Driver Update Program: http://driverupdateprogram.com/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# On est presque vendredi
Posté par davandg . Évalué à 4.
Génial, on va bientôt pouvoir avoir des drivers tout pourrit à télécharger sur touslescrapware.com dont l'installeur serra bourré de spywares ! J’espère qu'ils n'oublieront pas de faire un BSoD pour Linux, une idée pour la couleur ?
[^] # Re: On est presque vendredi
Posté par saltimbanque (site web personnel) . Évalué à 4.
celle là est un peu de mauvaise foi. pas plus tard qu'hier je n'ai pas sorti l'appareil photo en voyant dans un lieu public un panneau d'affichage kernel panic. Et non ce n'est pas plus joli qu'un écran bleu. En plus windows 8 a ajouté une emoticon à leur écran bleu, les kernel panic auraient pu se doter d'un peu d'ascii quand même.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 8.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: On est presque vendredi
Posté par Atem18 (site web personnel) . Évalué à 3.
Comme ça vient de SUSE, je penche pour le vert.
[^] # Re: On est presque vendredi
Posté par feth . Évalué à 2.
Pourquoi SuSE n'investit-elle pas le marché BSD, où tout est permis y compris de lier du code propriétaire à du code libre ?
[^] # Re: On est presque vendredi
Posté par bubar🦥 (site web personnel) . Évalué à 3. Dernière modification le 16 novembre 2013 à 10:45.
Peut être parcequ'elle n'est déjà pas capable de livrer un système qui reste cohérent entre leurs mises à jour ? Moi ça me laisse dubitatif de voir que la version de suse "for sap" pête la timezone sur une mise à jour : le boot.clock est celui d'origine, le /etc/sysc*/clock est celui avec les paramètres d'installation, le tout installé par un expert certifié, avec un suse-manager en version boite noire par novell… Mais SuSE arrive quant même à te changer la timezone en UTC, comme ça, paf la timezone [on passe sur l'abomination de l'utilitaire chargé de ça, et de sa manière de traiter ses tpl] Et ça se voit aussi lorsque tu regardes le fichier idoine dans l'initrd généré : TZ2\nTZ2\nUTC0 paf, alors que ça devrait être du TZ2\nCESTblabla. Forcément en changeant de timezone, le sap n'est pas très content.
Alors avec du *BSD, tu rêves mon ami :-)
[^] # Re: On est presque vendredi
Posté par bubar🦥 (site web personnel) . Évalué à 2.
Correctif : pour cette mauvaise aventure, qui a générée ce troll fort sur Novell SuSE, Novell n'est pas absolument pas en cause (c'est l'intégrateur qui a bidouillé à l'arrache ce qui a entrainé des incohérences)
Je fais amende honorable sur ce troll là, et présente mes excuses à la communauté OpenSUSE présente sur ce site.
# rêve ?
Posté par bubar🦥 (site web personnel) . Évalué à 1.
C'est plutôt un cauchemar …
# rétro-compatibilité
Posté par xcomcmdr . Évalué à 3.
Pareil pour un pilote Windows 7.
"Quand certains râlent contre systemd, d'autres s'attaquent aux vrais problèmes." (merci Sinma !)
[^] # Re: rétro-compatibilité
Posté par zebra3 . Évalué à 5.
J'aime bien le « 99% » :-)
Vu le nombre de drivers existants, ça en fait un paquet qui ne marchent plus. Et surtout, vu que le noyau est le même, pourquoi est-ce que ce n'est pas 100% ?
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: rétro-compatibilité
Posté par moi1392 . Évalué à 4.
ça dépends, si c'est 99% du driver ou 99% du code du driver qui est compatible, au final, aucun ne marche…
[^] # Re: rétro-compatibilité
Posté par pasBill pasGates . Évalué à -3.
Parce que t'as toujours un driver ici ou la qui fait des cochonneries plutot que respecter l'API publique.
# Pourquoi c'est...
Posté par deasy . Évalué à 1.
Sam from Microsoft qui annonce qqchose de Novell ?
Novell appartient à Microsoft ?
Voilà j'ai lancé mon troll, je m'enfuis vite. :D
[^] # Re: Pourquoi c'est...
Posté par Ermaion (site web personnel) . Évalué à 2.
Surtout que Suse est une entreprise indépendante depuis 2011
Source
Les liens semblent quant même différents désormais.
Maintenant je me pose en effet des questions sur les relations passées entre Mirosoft et Novell. C'est quant même cette collaboration qui à donnée lieu à Mono perçu comme le cheval de Troie de Microsoft.
[^] # Re: Pourquoi c'est...
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Enfin, c'est plus un pétard mouillé pour le moment !
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.