J'avais cru comprendre que le problème des ordiphones était lié à la non standardisation et au fait que les pilotes soient fermés : il leur faut un un OS spécifique, et des pilotes que seul le constructeur distribue. Donc s'il s'arrête, plus de mises à jour.
Il y a plusieurs problèmes.
Tout d'abord sur nos PCs, on a le BIOS / UEFI qui standardisent certaines interactions bas niveau et l'initialisation. C'est bien plus simple pour avoir un système unique qui fonctionne presque partout. Et de nos jours, beaucoup de protocoles gèrent la découverte du matériel à chaud comme PCIe, USB, etc.
Sur téléphone ce n'est pas le cas (ou disons moins le cas). Le matériel sur processeurs ARM doit souvent être décrit via un fichier spécial nommé device tree qui doit être chargé par le noyau pour charger les pilotes en guise de découverte du matériel.
Ensuite, chaque constructeur a sa couche bas niveau. Par exemple quand tu achètes un processeur Qualcomm quand tu t'appelles Sony, tu reçois le processeur évidemment mais aussi un noyau et quelques autres composants autour pour que tu puisses l'intégrer. Le noyau en particulier est très personnalisé, tu as des pilotes maison, des hacks ou autres correctifs pour optimiser les perfs ou certaines fonctionnalités. Seulement comme le noyau n'a pas une API interne stable et que ces correctifs n'intègrent pas le noyau officiel, tu as beau avoir les sources de ces changements, porter cela sur une version plus récente cela demande beaucoup de travail et de vérifications. Et comme Qualcomm et compagnie sont en mode je fournis et tu te démerdes les mises à jour sont rapidement difficiles.
Puis pendant longtemps comme tout le monde s'en foutait, il n'y a pas eu de gros efforts faits pour simplifier la tâche. Mais cela bouge doucement. Le noyau a des versions LTS prévisibles ce qui facilite la tâche pour les fondeurs type Qualcomm de faire leur travail sur un noyau qui va durer longtemps sans devoir faire la mise à jour du noyau dans une autre version tous les 4 matins. Google a travaillé pour rendre ses couches basses plus indépendantes des couches basses du constructeur pour qu'au moins tu puisses avoir un Android récent sur un noyau plus ancien. Je ne sais pas où s'en est et concrètement si cela fonctionne bien. Ils ont fait de même pour retirer certains trucs de ASOP pour les mettre dans leur service Google Play afin de ne pas trop être perturber par les surcouches constructeurs non plus. Et des constructeurs semblent vouloir faire un effort pour augmenter la durée des mises à jour comme Google et Samsung, mais certains s'en foutent encore royalement en particulier dans le bas de gamme.
Qu'est-ce qui pourrait être fait pour simplifier la tâche ? Déjà les constructeurs de puce pourraient mieux travailler avec les projets type Linux pour pousser leur travail plutôt que d'être en mode jetable. Il paraît qu'il y a eu un effort mais là encore j'ignore l'effectivité. Le noyau pourrait aussi assouplir sa politique vis à vis de l'API interne pour rendre cela plus stable et simplifier la maintenance à long terme pour les constructeurs. Les industriels pourraient aussi plus exploiter l'UEFI et des protocoles matériels plus adaptés pour rendre la plateforme ARM plus générique et simple pour le noyau et le système au dessus.
[^] # Re: Quelqu'un saurait m'expliquer ?
Posté par Renault (site web personnel) . En réponse au lien Fin du support logiciel sur le Fairphone 2 (mars 2023). Évalué à 10.
Il y a plusieurs problèmes.
Tout d'abord sur nos PCs, on a le BIOS / UEFI qui standardisent certaines interactions bas niveau et l'initialisation. C'est bien plus simple pour avoir un système unique qui fonctionne presque partout. Et de nos jours, beaucoup de protocoles gèrent la découverte du matériel à chaud comme PCIe, USB, etc.
Sur téléphone ce n'est pas le cas (ou disons moins le cas). Le matériel sur processeurs ARM doit souvent être décrit via un fichier spécial nommé device tree qui doit être chargé par le noyau pour charger les pilotes en guise de découverte du matériel.
Ensuite, chaque constructeur a sa couche bas niveau. Par exemple quand tu achètes un processeur Qualcomm quand tu t'appelles Sony, tu reçois le processeur évidemment mais aussi un noyau et quelques autres composants autour pour que tu puisses l'intégrer. Le noyau en particulier est très personnalisé, tu as des pilotes maison, des hacks ou autres correctifs pour optimiser les perfs ou certaines fonctionnalités. Seulement comme le noyau n'a pas une API interne stable et que ces correctifs n'intègrent pas le noyau officiel, tu as beau avoir les sources de ces changements, porter cela sur une version plus récente cela demande beaucoup de travail et de vérifications. Et comme Qualcomm et compagnie sont en mode je fournis et tu te démerdes les mises à jour sont rapidement difficiles.
Puis pendant longtemps comme tout le monde s'en foutait, il n'y a pas eu de gros efforts faits pour simplifier la tâche. Mais cela bouge doucement. Le noyau a des versions LTS prévisibles ce qui facilite la tâche pour les fondeurs type Qualcomm de faire leur travail sur un noyau qui va durer longtemps sans devoir faire la mise à jour du noyau dans une autre version tous les 4 matins. Google a travaillé pour rendre ses couches basses plus indépendantes des couches basses du constructeur pour qu'au moins tu puisses avoir un Android récent sur un noyau plus ancien. Je ne sais pas où s'en est et concrètement si cela fonctionne bien. Ils ont fait de même pour retirer certains trucs de ASOP pour les mettre dans leur service Google Play afin de ne pas trop être perturber par les surcouches constructeurs non plus. Et des constructeurs semblent vouloir faire un effort pour augmenter la durée des mises à jour comme Google et Samsung, mais certains s'en foutent encore royalement en particulier dans le bas de gamme.
Qu'est-ce qui pourrait être fait pour simplifier la tâche ? Déjà les constructeurs de puce pourraient mieux travailler avec les projets type Linux pour pousser leur travail plutôt que d'être en mode jetable. Il paraît qu'il y a eu un effort mais là encore j'ignore l'effectivité. Le noyau pourrait aussi assouplir sa politique vis à vis de l'API interne pour rendre cela plus stable et simplifier la maintenance à long terme pour les constructeurs. Les industriels pourraient aussi plus exploiter l'UEFI et des protocoles matériels plus adaptés pour rendre la plateforme ARM plus générique et simple pour le noyau et le système au dessus.