Oui, c’est le device tree. Mais une fois qu’il est écrit, il me semble qu’on pourrait l’utiliser avec n’importe quel noyau Linux avec la prise en charge du device tree non ? (je n’y connais pas grand chose).
Tout à fait. Mais tu oublies deux choses. Déjà pour en profiter au maximum, il faudrait que le device tree soit publié dans le noyau officiel. Or c'est très rarement le cas. Car pousser un commit dans le noyau ça prend du temps et les exigences sont telles que cela ne s'improvise pas.
Mais ce n'est qu'une partie du problème. Le point le plus délicat c'est la qualité des pilotes qui fait qu'ils ne sont pas utilisable dans le noyau Linux officiel. J'ai vu des pilotes de Texas Instrument de certains de leurs produits, ils ont limite refait une pile réseau et une pile SPI à eux. Comment veux-tu avec une qualité d'intégration du code si bas espérer que le noyau officiel (ou Google) prenne en charge la maintenance sur la durée ?
C'est vraiment un gros problème. Et ce problème est financier, mais aussi un manque de culture de la part de ces entreprises. Cela demandera forcément du temps pour que cela change.
et fournissent un tas de pilotes propriétaires qui rendent de toute façon difficile le port d’un nouveau noyau sur leur puce.
Grâce à la GPL, les pilotes en question sont rarement propriétaires. Mais le travail effectué est de basse qualité et demande un gros effort pour espérer le publier au noyau officiel.
Malgré tout, cela ne devrait pas empêcher au moins la partie d’Android en espace utilisateur de recevoir des mises à jour sans grande difficulté.
Je crois que c'est sur cet axe que Google travaille actuellement. Cela résoudrait en effet une partie du problème bien que d'avoir un noyau à jour devrait être recherché également.
Après cela pose des contraintes, Google exploite et pousse pas mal de choses au niveau du noyau pour que l'espace utilisateur en tire profit. Que ce soit pour l'économie d'énergie, la sécurité, etc. C'est peut être une explication du couplage fort actuel entre l'espace utilisateur et le noyau au niveau d'Android. Mais je ne suis pas expert Android à ce point pour le juger.
Par exemple je crois me souvenir que le sous système iio provient en partie de la demande croissante des téléphones pour ce genre de périphériques. Et ce sous système a beaucoup évolué en peu de temps.
C’est quand même bien le bazar.
Oui, je le concède.
Après avoir pointé du doigt Google et les constructeurs, on oublie un élément central aussi : le noyau Linux lui même.
D'un point de vue développement, Linux a toujours pris le parti pris d'avoir une ABI externe stable (entre le noyau et un logiciel en espace utilisateur) mais une API interne instable (entre un pilote et le cœur du noyau par exemple). Cela rend le travail de maintenance des pilotes plus lourde, surtout si tu ne parviens pas à faire accepter ce travail upstream.
L'avantage cependant c'est que l'API du noyau Linux évolue très vite et peut proposer pas mal de choses rapidement tout en faisant bénéficier des anciens modules d'entrée de jeu.
C'est un choix, un compromis, mais il faut accepter la contrepartie d'un tel choix qui n'aide vraiment pas la situation d'Android.
[^] # Re: Pourquoi avoir peur du reconditionné ?
Posté par Renault (site web personnel) . En réponse à la dépêche Mon nouveau smartphone Android dégooglisé. Évalué à 5.
Tout à fait. Mais tu oublies deux choses. Déjà pour en profiter au maximum, il faudrait que le device tree soit publié dans le noyau officiel. Or c'est très rarement le cas. Car pousser un commit dans le noyau ça prend du temps et les exigences sont telles que cela ne s'improvise pas.
Mais ce n'est qu'une partie du problème. Le point le plus délicat c'est la qualité des pilotes qui fait qu'ils ne sont pas utilisable dans le noyau Linux officiel. J'ai vu des pilotes de Texas Instrument de certains de leurs produits, ils ont limite refait une pile réseau et une pile SPI à eux. Comment veux-tu avec une qualité d'intégration du code si bas espérer que le noyau officiel (ou Google) prenne en charge la maintenance sur la durée ?
C'est vraiment un gros problème. Et ce problème est financier, mais aussi un manque de culture de la part de ces entreprises. Cela demandera forcément du temps pour que cela change.
Grâce à la GPL, les pilotes en question sont rarement propriétaires. Mais le travail effectué est de basse qualité et demande un gros effort pour espérer le publier au noyau officiel.
Je crois que c'est sur cet axe que Google travaille actuellement. Cela résoudrait en effet une partie du problème bien que d'avoir un noyau à jour devrait être recherché également.
Après cela pose des contraintes, Google exploite et pousse pas mal de choses au niveau du noyau pour que l'espace utilisateur en tire profit. Que ce soit pour l'économie d'énergie, la sécurité, etc. C'est peut être une explication du couplage fort actuel entre l'espace utilisateur et le noyau au niveau d'Android. Mais je ne suis pas expert Android à ce point pour le juger.
Par exemple je crois me souvenir que le sous système iio provient en partie de la demande croissante des téléphones pour ce genre de périphériques. Et ce sous système a beaucoup évolué en peu de temps.
Oui, je le concède.
Après avoir pointé du doigt Google et les constructeurs, on oublie un élément central aussi : le noyau Linux lui même.
D'un point de vue développement, Linux a toujours pris le parti pris d'avoir une ABI externe stable (entre le noyau et un logiciel en espace utilisateur) mais une API interne instable (entre un pilote et le cœur du noyau par exemple). Cela rend le travail de maintenance des pilotes plus lourde, surtout si tu ne parviens pas à faire accepter ce travail upstream.
L'avantage cependant c'est que l'API du noyau Linux évolue très vite et peut proposer pas mal de choses rapidement tout en faisant bénéficier des anciens modules d'entrée de jeu.
C'est un choix, un compromis, mais il faut accepter la contrepartie d'un tel choix qui n'aide vraiment pas la situation d'Android.