Bonjour,
en lisant mon site prefere, je fut surpris de voir une absurdité de la part d'un homme qui se prend au serieux ;:
"Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau"
Comment peut on dire un truc pareil ? Dans une interface, il y a le côté système qui, bien entendu, se doit d'évoluer au fur et à mesure que le développement du noyau se fait.
L'autre face (dit API ?) doit être destinée aux utilisateurs, aux développeurs tiers... avec une documentation précise.
Dans la première année d'une école d'ingénieur, on nous apprend que tout système multi-couche doit être accompagnée d'une interface programmable capable de s'adapter avec les évolutions des sous-couches tut en ne mettant pas par terre les programmes tiers s'y greffant.
Grosso modo cela voudrait dire que Linux est mal foutu, mal programmé, pas bien conçu, bancal et sans avenir. J'espere que cela est faux, car sinon on est mal barré.
Imaginez Java. Vous avez programmé quelque chose en 1.3.1
Si Sun faisait ce que le monsieur disait, cela voudrait dire que si vous installez Java 1.3.2 bien vos programmes ne fonctionneraient pas.
Absurdité ! On sait très bien que les gens de Sun eux sont d'excellents programmeurs, et non seulement nos programmes Java fonctionnent avec les version récentes de JRE, mais non seulement ils répondent de mieux en mieux
Les développeurs Linux devraient prendre de la graine sur les développeurs Java...
Journal Linux et les pilotes binaires...
10
déc.
2005
# au risque de te décevoir
Posté par nicodache . Évalué à 8.
Il est donc fort logique de voir que le code source de linux est pas aussi clean que tu le voudrais.
il est certes pas très bien conçu, ni très stable, mais il a part contre un immense avenir, et dans le pire des cas, un petit cousin mieux étudié, hurd.
quant à ton exemple java, tu n'as visiblement jamais vu de fonctions java deprecated, et tu n'a jamais eu de problème pour faire tourner un truc basique en java 1.4 (genre 2 tableaux) sur une jvm 1.3.
ni le contraire, faire tourner un programme 1.3 sur la jvm1.5
d'accord, les risques d'incompatibilités sont clairements annoncés et documentés sur java.sun.com, mais de la à dire que linus et ses copains devraient apprendre à gérer un projet sur base de java, ca me semble un rien aberrant...
qqun confirme mon point de vue ?
[^] # Re: au risque de te décevoir
Posté par Weinstock Serge . Évalué à 4.
et pendant qu'on y est, changeons les API posix!!! Porquoi s'embarrasser de compatibilte entre les differents Unix? Linux avant tout!:)
Et rendons obligatoire les changements d'API tous les six mois. Comme ca tous les programmes devront etre reecrits tous les six mois!
Ah j'oubliais, tous les six mois tous les automobilistes devront rouler a gauche et tous les six mois ils devront rouler a droite! :)
Vive la revolution!
Blague a part, je suis tout a fait d'accord avec Samuel, cette histoire de changement d'API est une pure absudite.
Il faut te rendre compte que le development de Linux implique des milliers de developpeurs et pour que cela marche on doit fixer un certain nombre de regles du jeu et cela s'appelle des APIs.
Serge
[^] # Re: au risque de te décevoir
Posté par chtitux (site web personnel) . Évalué à 10.
Bonne idée !
Et si on changeait le côté du stationnement toutes les quinzaines ?
15 jours à droite, 15 jours à gauche ?
# Je ne pas confondre ABI et API !
Posté par inico (site web personnel) . Évalué à 9.
Par contre l'API devrait être stabilisé enfin c'est toujours le probléme de ce genre de programme.
ABI: interface de comptabilité binaire
API: (je dois vraiment definir ?)
[^] # Re: Je ne pas confondre ABI et API !
Posté par benoar . Évalué à 10.
Dans le noyau on trouve principalement comme types de données des types de base (char, short, int, ...), des structs et des tableaux, L'API des sous-ensembles du noyau (pci, usb, vm, ...) définit un ensemble de de fonctions opérant sur ces types. Comme le précise inico, elle est plutôt stable.
Quand ces types sont utilisés dans un code source, on les appelle par leur nom. Pour les types de bases, ils peuvent être "aliasés" (avec un typedef) quand ils ne sont pas manipulés directement par l'utilisateur de l'API (en général). Pour les structs, chacun de ses membres a un nom. Pour les tableaux, on indique un indice qui désigne l'élément d'un certain type (de base, ou un struct, ou un autre tableau).
Tout ça, avec les fonctions, forme l'API, c'est compréhensible par un humain car c'est du code _source_. Le nom des types, des membres des structs restent les même pour chaque version majeure de l'API.
Vient ensuite l'étape de la compilation. C'est alors que tout se corse pour l'humain : les types "aliasés" sont "traduis" en leur type de base, les membres des structs deviennent des offsets par rapport à l'adresse de base de la struct, les indices des tableaux sont aussi des offsets par rapport au début du tableau. Heureusement qu'on a gardé le linkage dynamique des fonctions (qui gardent donc leur nom et ne deviennent pas (directement) des nombres mais restent des symboles) sinon tout cet étalage de nombres vu par un humain parraitrait un beau bordel (ceux qui suivent jusqu'ici doivent se dire que je suis maso de ne pas déjà trouver ça un beau bordel, mais SI, l'assembleur c'est bô).
Et c'est là que ça se corse pour les drivers binaires. La traduction précédente est effectuée en ayant une certaine définition de ces types & structs. Si un alias d'un type change (par exemple size_t devient unsigned short au lieu d'unsigned int) alors la "traduction" en code binaire ne sera pas la même, ou alors si un membre d'une struct est ajouté (même s'il ne fait pas partie de l'API, mais est utilisé en interne par exemple), tous les offsets de cette structure vont changer (ainsi que sa taille, pensez au sizeof()), ou si le types d'un tableau change, les offsets seront calculés différemment (je rappelle que ((char*)foo)[2] donne un résultat complètement différent de ((int *)foo)[2], même s'ils sont castés vers le même type après).
Et tout cela SANS que l'API ait changé. Une simple recompilation aurait suffit pour un driver dont on a les sources.
Donc l'ABI est complètement différente de l'API, merci inico de l'avoir rappelé.
[^] # Re: Je ne pas confondre ABI et API !
Posté par cosmocat . Évalué à 2.
Avec Gcc il me semble que des qu'il sont obligé de casser l'ABI, le compilateur change de numéro majeur de version.
Gcc 4 n'est donc pas compatible avec gcc3.
Confirmation???
[^] # Re: Je ne pas confondre ABI et API !
Posté par nicodache . Évalué à 1.
des histoires de package-machin-1.2.3c2 je crois
[^] # Re: Je ne pas confondre ABI et API !
Posté par Sylvain Sauvage . Évalué à 3.
D'où les problèmes de dépendances des paquets KDE (écrit en C++).
c2 : version 2 de l'ABI.
# ouais, enfin...
Posté par Nicolas Bernard (site web personnel) . Évalué à 10.
Le reste, c'est à l'intérieur du noyau lui même, donc ça me semble un peu normal que ça change...
Ta comparaison avec Java n'a pas de sens: un programmeur java utilise l'interface "externe" du langage. Il ne voit pas si les interfaces des modules internes qui implémentent le langage changent ou non (car il n'y a pas accès).
[^] # Re: ouais, enfin...
Posté par Joris Dedieu (site web personnel) . Évalué à -6.
Y a pas des API pour développer les pilotes ??
Ta comparaison avec Java n'a pas de sens
C'est sur on va pas commencer à faire des tests de non régression au niveau du noyau ;-\
# Meuh powah
Posté par Grumbl . Évalué à 10.
Les universitaires aiment bien considérer, pour d'évidentes raisons pratiques, qu'un developpeur sait ce qu'il fait avant de commencer à travailler. En théorie, des gens vachement intelkligents sont apssés avant, ont posé le bon problème, trouvé la meilleure solution au problème posé, une architecture de solution a été définie et un processus de developpement déterminé. C'est très rassurant pour le manager qui ne saurait envisager d'autre approche pour un projet que linéaire (des étapes à franchir et des cases à cocher sur la todolist).
Malheuresement, il s'avère que certains programmeurs ne souhaitent pas procéder ainsi. Par exemple, parce qu'ils n'ont pas pris le temps de rédgier l'énoncé du problème et n'ont qu'une vague idée d'une classe de solutions, et que leur performance (appréciée par eux mêmes ou leurs proches) leur tient lieu de méthode. Cela arrive quand, par exemple, faute d'avoir reçu les bons conseils du génie logiciel universitaire, ils admettent tout simplement qu'ils vont commencer à programmer avant de savoir ce à quoi le fait de programmer va les mener.
Et notamment, il arrive que, bien qu'on essaie de bosser un peu sérieusement, publier des spécification d'interface publique, toussa, on se rende compte au bout d'un certain temps que le design qu'on avait choisi était foireux.
Quand on a le source des deux côtés de l'interface, ça ne pose normalement aucun problème. Donc, ne pas disposer d'interfaces publiques stables et documentées n'est pas forcément bloquant pour qui que ce soit, à condition d'exposer non seulement l'interface, mais aussi les mécanismes d'interfaçage, ce qui se fait suffisamment efficacement en exposant le source (car source==doc, n'est-ce pas ?). D'ailleurs, on peut aussi publier en annexe un fichier surdétaillant l'interface destiné à être intégré compile-time ou runtime avec tout produit se greffant.
Et une chose est certaine : c'est que quand on a pas besoin de béquilles pour avancer, il arrive qu'on aille plus vite, même si on se casse plus souvent la gueule, entrainant parfois avec soi quelques voisins ou compagnons d'aventure. Pour les premiers, programmer devient prévisible, en un mot, professionnel : ce peut donc être devenir un métier, une profession, pour les seconds, c'est une passion. Quand à savoir lequel est le plus efficace des deux, c'est un autre débat... les moyens dont disposent les uns et les autres ne sont nullmement comparbales?.
# Du coté de chez Redmond ...
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
La compatibilité binaire d'une version à l'autre, c'est une contrainte, c'est sur. Que les développeurs du noyau n'aient pas envie de se fixer cette contrainte, c'est une chose, mais qu'on nous fasse croire que c'est complètement impossible, c'est une ânerie.
[^] # Re: Du coté de chez Redmond ...
Posté par soulflyb (Mastodon) . Évalué à 10.
ben quand on voit ce que ça donne chez redmond .... on comprend que les dev linux n'aient pas envie de faire pareil ;)
plus sérieusement, je pense que la problématique _à l'origine_ n'existait pas, linux était un os open-source (ça n'a pas beaucoup changé d'ailleurs ;) ) et il n'y avait donc aucune raison de fournir une compatibilité binaire extrêmement contraignante
c'est seulement l'arrivée de drivers proprio closed-source qui fout le bordel .... dans notre monde, c'est la compatibilité des sources qui est la norme, ce qui donne plus de marge de manoeuvre aux développeurs, alors pourquoi s'embêter à s'adapter à des méthodes closed-source alors que c'est le contraire qui devrait avoir lieu, non ? (oui, je sais, ce n'est pas très pragmatique ce que je dis).
En tout cas, une chose est sûre :
.... c'était mieux avant ;)
[^] # Re: Du coté de chez Redmond ...
Posté par Krunch (site web personnel) . Évalué à 4.
http://blogs.msdn.com/oldnewthing/archive/2003/10/15/55296.a(...)
http://blogs.msdn.com/oldnewthing/archive/2003/12/23/45481.a(...)
Changer l'ABI régulièrement permet au moins de casser les applications mal écrites :op
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Du coté de chez Redmond ...
Posté par Leroy Frederic (site web personnel) . Évalué à 1.
C'est plutôt le travail des distributeurs de proposer un environnement avec abi stable.
[^] # Re: Du coté de chez Redmond ...
Posté par pasBill pasGates . Évalué à 1.
Desole mais ca n'a rien a voir.
Windows NT quand il tournait sur MIPS/PPC/x86/Alpha il avait une ABI stable qui ne changeait pas tous les 3 jours.
L'ABI du kernel ca n'a pas grand-chose a voir avec la plateforme materielle en dessous. Si l'ABI est faite correctement c'est vraiment pas un probleme.
# Alan Cox ?
Posté par herodiade . Évalué à 4.
en lisant mon site prefere, je fut surpris de voir une absurdité de la part d'un homme qui se prend au serieux ;:
"Pour que les pilotes binaires fonctionnent bien, il faut une interface avec le noyau qui ne change pas. Cela est une aberration technique, car une interface gelée freinerait grandement le développement du noyau"
C'est bien Alan Cox ? En fait, c'est réellement un developpeur sérieux, et tu devrait réviser ton analyse ...
[^] # Re: Alan Cox ?
Posté par mickabouille . Évalué à 2.
Bien sûr, son avis est aussi l'avis de beaucoup de développeurs du noyau. Peut être aussi d'AC.
[^] # Re: Alan Cox ?
Posté par pasBill pasGates . Évalué à 2.
Si je te sors 2 developpeurs serieux, disant des trucs opposes, comment savoir qui a raison ?
Ben oui, se baser sur la reputation du gars pour juger de ce qu'il dit n'est pas une technique efficace, mieux vaut ecouter ce qu'il dit, comparer avec les faits et se faire une opinion.
# Mhhhh... sacré Sam...
Posté par lesensei . Évalué à 8.
D'abord, je suis surpris de voir la quantité de posts qui comparent sans se poser plus de questions les mode closed-source et open-source de développement.
Quelqu'un comparait plus haut la compatibilité binaire de Windows, de MacOS et de Linux. Bon alors, d'abord, définissons bien le domaine d'étude: on parle là de compatibilité BINAIRE des NOYAUX. Ça fait une grosse différence, puisque celle-ci a été largement cassée dans Windows lors du passage au noyau NT 5. Si, si, souvenez-vous, Windows 2000 a démarré lentement en partie à cause de ça (je continue pourtant de penser que c'était la meilleure version).
Ensuite, la personne parlait de MacOS X, en admettant qu'elle n'en savait rien, d'ailleurs, ce qui n'a pas manqué de me faire sourire. Là encore, à chaque changement majeur de version des pilotes tierce partie se retrouve cassés. Les pilotes tierce-partie sont encore plus rares sous OS X que sous Linux, donc ça se voit pas trop, mais par exemple, le pilote ext2fs est encore en phase de stabilisation pour 10.4, sorti depuis un moment maintenant... et pourtant, le code du noyau de OS X est open source. Simplement, il n'est pas développé en utilisant un serveur de versionnement ouvert à tous, donc il est difficile d'adapter les drivers au fur et à mesure.
Pour finir, la réponse à la "question" de Sam est donnée dans la petite fiction sur le problème en question, n'est-ce pas... il peut être nécessaire de casser la compatibilité pour de bonnes raisons, même sans changer de numéro majeur de version, par exemple pour des raisons de sécurité. Bref, un troll qui, à mon avis, n'est rien de plus que ça, justement...
[^] # Re: Mhhhh... sacré Sam...
Posté par pasBill pasGates . Évalué à 1.
La compatibilite binaire n'a pas ete cassee du tout, il y a plein de drivers NT4 qui fonctionnent sur Win2000.
Il y a eu plein d'ajouts de features par contre et c'est ce qui a fait peur aux gens, ils se sont dit que MS ne pourrait pas faire un OS stable avec tant de changements, et ils ont donc attendu pour voir le resultat.
[^] # Re: Mhhhh... sacré Sam...
Posté par lesensei . Évalué à 1.
En gros, tu dis la même chose que moi, mais avec les mots qui t'arrangent...
Je parlais bien sûr de la compatibilité entre les versions "grand public" de Windows. Car 2000 avait au début été présenté comme tel, avant que Me n'arrive sur le marché. Et, mais c'est mon analyse, si Me (non basé sur le noyau NT) est arrivé sur le marché, c'est parce qu'un certain nombre de constructeurs n'ont pas voulu faire de drivers pour leur matériel sous 2000. Et c'est justement la situation que les développeurs du noyau Linux veulent éviter: avoir à sortir de nouvelles versions d'un vieux noyau pour permettre à des pilotes binaires de rester utilisables. Surtout compte-tenu que cela risque de rendre extrêmement difficile la correction de problèmes de sécurité liés au design des APIs linux.
[^] # Re: Mhhhh... sacré Sam...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Si Linux 2.6 ne souhaite pas une compatibilité binaire avec la version 1.0, je peux le comprendre, mais qu'on me fasse croire que tout casser à chaque version mineure est _nécessaire_ (je me souviens encore d'un changement d'API - même pas d'ABI - entre qq chose comme le 2.6.5 et le 2.6.6 qui a cassé mon driver eagle-usb), c'est n'importe quoi. Qu'il fassent ce choix, c'est une chose. Qu'ils nient la possibilité de faire autrement, c'en est une autre.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.