Quand tu as une API stable, tu peux au moins essayer de l'utiliser, et de faire ton driver crade comme tu veux de ton côté avec. Si ça marche pas, tu peux alors faire l'effort de faire des changements dans le noyau. Mais ça rend tout de suite clair dans quoi tu te lances: il va falloir récupérer les sources du noyau, le recompiler, faire les changements, puis maintenir ce fork.
ça ne rend pas le code automatiquement de meilleure qualité hein. Mais par contre, ça force les gens à se dire "ouhlà, j'ai franchi la ligne rouge". À mon avis, ça rend juste les choses assez pénibles à faire pour que le dev se pose deux minutes et se demande s'il a pas moyen d'arriver à faire ce qu'il veut avec l'API qu'on lui a donné. Pas parce que c'est plus propre, mais parce que ça l'embête de devoir recompiler le noyau et pas juste son bout de driver.
Dans le fonctionnement actuel, c'est un peu "voilà les sources du noyau, débrouille-toi avec ça". Et c'est considéré normal que chaque pilote écrit aie besoin de réécrire la moitié du noyau (j'ai arrêté de compter combien de fois ils ont changé la stratéglie d'allocation mémoire pour les pilotes graphiques, par exemple).
En ce qui concerne l'unicité du matériel, ARM a fait pas mal de progrès pour tout ce qui est de base. Tu as une MMU standard, ainsi qu'un timer système pour faire tourner un scheduler. Déjà c'est pas mal. Autour de ça, il commence aussi à y avoir des standards de fait sur certains autres points. Par exemple, sur n'importe quelle plateforme ARM tu as toutes les chances de trouver une UART compatible 16C550 (la même qui pilote les ports série sur PC). Après pour les trucs plus avancés, cartes graphiques, etc, oui, c'est pas standard. Sur PC non plus, mais le BIOS dépanne en fournissant au moins un mode texte et du VESA pour pouvoir afficher des pixels sans accélération. Mais c'est pas vraiment là qu'est le gros du travail, en fait.
C'est vrai que c'est plus diversifié que sur l'architecture PC/x86, mais quand même, ça ne me semble pas insurmontable si les choses sont faites un minimum proprement.
[^] # Re: Dommage que la fondation Mozilla n'ai pas fait pareil avec Firefox os
Posté par pulkomandy (site web personnel, Mastodon) . En réponse à la dépêche Librem 5, un projet de téléphone mobile libre tournant sous GNU/Linux !. Évalué à 4.
Quand tu as une API stable, tu peux au moins essayer de l'utiliser, et de faire ton driver crade comme tu veux de ton côté avec. Si ça marche pas, tu peux alors faire l'effort de faire des changements dans le noyau. Mais ça rend tout de suite clair dans quoi tu te lances: il va falloir récupérer les sources du noyau, le recompiler, faire les changements, puis maintenir ce fork.
ça ne rend pas le code automatiquement de meilleure qualité hein. Mais par contre, ça force les gens à se dire "ouhlà, j'ai franchi la ligne rouge". À mon avis, ça rend juste les choses assez pénibles à faire pour que le dev se pose deux minutes et se demande s'il a pas moyen d'arriver à faire ce qu'il veut avec l'API qu'on lui a donné. Pas parce que c'est plus propre, mais parce que ça l'embête de devoir recompiler le noyau et pas juste son bout de driver.
Dans le fonctionnement actuel, c'est un peu "voilà les sources du noyau, débrouille-toi avec ça". Et c'est considéré normal que chaque pilote écrit aie besoin de réécrire la moitié du noyau (j'ai arrêté de compter combien de fois ils ont changé la stratéglie d'allocation mémoire pour les pilotes graphiques, par exemple).
En ce qui concerne l'unicité du matériel, ARM a fait pas mal de progrès pour tout ce qui est de base. Tu as une MMU standard, ainsi qu'un timer système pour faire tourner un scheduler. Déjà c'est pas mal. Autour de ça, il commence aussi à y avoir des standards de fait sur certains autres points. Par exemple, sur n'importe quelle plateforme ARM tu as toutes les chances de trouver une UART compatible 16C550 (la même qui pilote les ports série sur PC). Après pour les trucs plus avancés, cartes graphiques, etc, oui, c'est pas standard. Sur PC non plus, mais le BIOS dépanne en fournissant au moins un mode texte et du VESA pour pouvoir afficher des pixels sans accélération. Mais c'est pas vraiment là qu'est le gros du travail, en fait.
C'est vrai que c'est plus diversifié que sur l'architecture PC/x86, mais quand même, ça ne me semble pas insurmontable si les choses sont faites un minimum proprement.