Un fabricant de hardware a aussi la mauvaise habitude de ne plus se soucier de son hard une fois que la version suivante est en production. Il a aussi une vision assez spécial du logiciel qui est censé être omniscient. J'ai déjà vu des spec logiciel pour un soc qui contenait plusieurs cpu qui tournaient sous 2 os différent dont l'un temps réel. Ces 2 OS attaquaient des périphériques différents mais pouvait avoir accès à des registres commun pour la gestion de l'horloge (et donc indirectement la gestion de l'énergie). Il était donc spécifié l'utilisation d'un sémaphore entre les 2 OS avec un support hardware car le bus interne ne supportait pas le read-modify-write. Simple, non ?
A l'inverse l'arbre d'horloge que l'on retrouve dans un clk.h des sources de linux peut être énorme et généré automatiquement directement avec les sources du hardware du SoC. C'est simple aussi parce que Linux a définit une interface standard.
En gros, le fabricant de hardware pourrait fournir des fonctions de haut niveau de son SoC, un peu comme la continuité de son hardware, en respectant la modularisation par périphérique, mais sans toucher à la complexité d'un OS comme la gestion de ressource critique, le multithread, la gestion mémoire, les politiques d’ordonnancement, etc… Cela serait juste une série de fonction à utiliser par l'OS.
[^] # Re: Second degré...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Quand Linus énervé, Linus faire ça !. Évalué à 3.
Un fabricant de hardware a aussi la mauvaise habitude de ne plus se soucier de son hard une fois que la version suivante est en production. Il a aussi une vision assez spécial du logiciel qui est censé être omniscient. J'ai déjà vu des spec logiciel pour un soc qui contenait plusieurs cpu qui tournaient sous 2 os différent dont l'un temps réel. Ces 2 OS attaquaient des périphériques différents mais pouvait avoir accès à des registres commun pour la gestion de l'horloge (et donc indirectement la gestion de l'énergie). Il était donc spécifié l'utilisation d'un sémaphore entre les 2 OS avec un support hardware car le bus interne ne supportait pas le read-modify-write. Simple, non ?
A l'inverse l'arbre d'horloge que l'on retrouve dans un clk.h des sources de linux peut être énorme et généré automatiquement directement avec les sources du hardware du SoC. C'est simple aussi parce que Linux a définit une interface standard.
En gros, le fabricant de hardware pourrait fournir des fonctions de haut niveau de son SoC, un peu comme la continuité de son hardware, en respectant la modularisation par périphérique, mais sans toucher à la complexité d'un OS comme la gestion de ressource critique, le multithread, la gestion mémoire, les politiques d’ordonnancement, etc… Cela serait juste une série de fonction à utiliser par l'OS.
"La première sécurité est la liberté"