Moui... Pour moi c'est plutôt Linux qui a mis beaucoup trop de temps à réagir et à mettre en place les device trees pour les architectures ARM. Résultat, les constructeurs n'ont pas eu trop de choix que de bricoler avec ce qu'ils avaient sous la main.
Devicetree ou pas, les constructeurs qui ne s'investissent pas upstream font de la merde, tout simplement. Le devicetree n'est qu'une petite partie du problème, je vais l'expliquer après.
Le devicetree ne servant qu'à décrire ce qui est dispo sur la carte, ce n'est pas un pilote, ni un sous-système du noyau (là où résident l'essentiel des problèmes).
Le BIOS n'y est pour rien, dans les PC il n'est quasiment pas utilisé par Linux (un peu par GRUB, mais c'est tout) et sur la plupart des machines ARM tu vas trouver un u-boot qui fait tout aussi bien et même mieux dans la plupart des cas (rappelons que le BIOS ça date des années 70, quand même).
Sur ARM il y a beaucoup de choses à encoder en dur pour chaque plateforme car cela manque clairement d'unicité. Sur PC, soit tu as des possibilités d'énumérations, soit les processeurs sont suffisamment proches pour que cela ne pose pas une grande difficulté.
Si Linux avait une API stable pour les drivers et qu'on pouvait les maintenir séparément et indépendamment de la version du noyau, ça serait simple de garder les drivers du fabricant et de mettre à jour le noyau.
Au final, pour un fabricant de puces, ça coûte moins d'effort de faire un truc rapide et pas propre et pas intégrable, et y'a pas vraiment de raison de faire autrement.
Oui et non.
Oui, je le reconnais que c'est un problème, ça complexifie la tâche, c'est évident.
Mais ce n'est pas dit que cela résolve tout non plus. Il suffit de voir ce que font les constructeurs (Texas Instrument, Broadcom ou Qualcomm par exemple) pour se convaincre qu'une API noyau stable n'est pas une solution pour eux.
Car leur travail est globalement crade. S'ils ne codent pas proprement dans leur propre fork du noyau, je doute qu'ils fassent cet effort avec un API stable. Quand tu as dans un même sous-système d'un constructeur 4 versions du booléen, tu deviens chèvre. Bool, bool, _Bool et _bool.
Quand ils utilisent leur propre pile réseau (ou une partie) plutôt que de changer celle du noyau et que bien sûr leur pilote en dépend entièrement, tu vois bien qu'il y a un soucis de conception.
On sent bien que globalement les équipes derrière ça n'ont pas le temps ou les ressources de faire un travail de qualité suffisante pour inclure ça dans le noyau officiel. C'est un patchwork assez ignoble.
Si l'absence d'API stable est un soucis, ce n'est clairement pas de cette seule responsabilité.
[^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os
Posté par Renault (site web personnel) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 6.
Devicetree ou pas, les constructeurs qui ne s'investissent pas upstream font de la merde, tout simplement. Le devicetree n'est qu'une petite partie du problème, je vais l'expliquer après.
Le devicetree ne servant qu'à décrire ce qui est dispo sur la carte, ce n'est pas un pilote, ni un sous-système du noyau (là où résident l'essentiel des problèmes).
Sur ARM il y a beaucoup de choses à encoder en dur pour chaque plateforme car cela manque clairement d'unicité. Sur PC, soit tu as des possibilités d'énumérations, soit les processeurs sont suffisamment proches pour que cela ne pose pas une grande difficulté.
Oui et non.
Oui, je le reconnais que c'est un problème, ça complexifie la tâche, c'est évident.
Mais ce n'est pas dit que cela résolve tout non plus. Il suffit de voir ce que font les constructeurs (Texas Instrument, Broadcom ou Qualcomm par exemple) pour se convaincre qu'une API noyau stable n'est pas une solution pour eux.
Car leur travail est globalement crade. S'ils ne codent pas proprement dans leur propre fork du noyau, je doute qu'ils fassent cet effort avec un API stable. Quand tu as dans un même sous-système d'un constructeur 4 versions du booléen, tu deviens chèvre. Bool, bool, _Bool et _bool.
Quand ils utilisent leur propre pile réseau (ou une partie) plutôt que de changer celle du noyau et que bien sûr leur pilote en dépend entièrement, tu vois bien qu'il y a un soucis de conception.
On sent bien que globalement les équipes derrière ça n'ont pas le temps ou les ressources de faire un travail de qualité suffisante pour inclure ça dans le noyau officiel. C'est un patchwork assez ignoble.
Si l'absence d'API stable est un soucis, ce n'est clairement pas de cette seule responsabilité.