> Par exemple, pour la MMU, c'est pas parce que c'est utilise essentiellement par VMM (le sous-systeme de gestion de la mem virtuelle) que ca ne doit pas etre une API a part entiere, claire et precise.
Je suis parfaitement d'accord. Mais lorsqu'on parle API il faut être précis. Si on me parle d'API de la vmm sans plus de précision, je pense à l'API utilisable par un module externe et pas au sein du système de gestion de la vmm.
Si je dis que l'API de libxml2 est bien faite, tout le monde comprend que je parle de l'API "externe" et pas de la tembouille interne.
> Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi.
Pas totalement d'accord. Dans l'idéal, ça doit être le même code. Ce qui compte avant tout c'est que l'interface, l'API "externe", soit la même pour tout le monde.
De tout manière, il est *impossible* d'avoir le même code pour toute les architectures, ou plus précisément il y a toujours un moment ou tu dois prendre en compte les spécificité de l'architecture pour des raisons de performance. C'est bien le role du noyau (ou de tout module réutilisable) de prendre en compte les spécificités et de les masquer. Mais au final il faudra *toujours* du code spécifique.
> Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?
Tu peux toujours repousser l'encapsulation. Savoir où et jusqu'où il faut le faire n'est en rien évident (surtout pour un noyau ou le critère performance est très important).
Tu peux faire un noyau en java, mais c'est lent et le code spécifique que tu as retiré en utilisant java, tu le retrouves dans java. Le gain est nul.
> D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.
L'interface (externe) se passe de ce genre de détail (sauf pour quelques cas rarement utilisé). Donc la voie est libre pour implémenter différement la VMM où même faire une VMM totalement spécifique à ppc sans retoucher (ou peu) l'API externe.
Au final et pour être bien d'accord. Je ne vais pas dire les avantages ou inconvénient des techniques de telle ou telle vmm. Je n'ai pas les compétences. Ce qui m'"énerve" c'est de voir les gens parler d'_API_ en des définissants comme spécifiques à une architecture.
Ce que tu reproches à la vmm ici (et si j'ai bien compris) a du sens. Tu ne reproches pas l'API (externe) mais que la vmm "colle" que système qu'on retrouve sur les systèmes types x86 et que ce n'est pas forcement la bonne aproche pour toutes les architectures. Tu ne demandes pas que l'API (externe) soit encore plus neutre par rapport au architecture mais que son fonctionnement interne soit plus neutre et pas "optimisé" pour un type d'architecture.
Je n'ai pas de problème avec ça.
[^] # Re: Il manque
Posté par fabb . En réponse à la dépêche Sortie du noyau 2.6.11. Évalué à 1.
Je suis parfaitement d'accord. Mais lorsqu'on parle API il faut être précis. Si on me parle d'API de la vmm sans plus de précision, je pense à l'API utilisable par un module externe et pas au sein du système de gestion de la vmm.
Si je dis que l'API de libxml2 est bien faite, tout le monde comprend que je parle de l'API "externe" et pas de la tembouille interne.
> Dans Linux comme dans les Unix, la VMM, interne au noyau, doit avoir le meme comportement dans toutes les archi, et donc, si possible *partager* le meme code pour toutes les archi.
Pas totalement d'accord. Dans l'idéal, ça doit être le même code. Ce qui compte avant tout c'est que l'interface, l'API "externe", soit la même pour tout le monde.
De tout manière, il est *impossible* d'avoir le même code pour toute les architectures, ou plus précisément il y a toujours un moment ou tu dois prendre en compte les spécificité de l'architecture pour des raisons de performance. C'est bien le role du noyau (ou de tout module réutilisable) de prendre en compte les spécificités et de les masquer. Mais au final il faudra *toujours* du code spécifique.
> Quelle autre solution pour ca que de dire que VMM repose sur une API de gestion de la MMU uniforme sur toutes les archis ?
Tu peux toujours repousser l'encapsulation. Savoir où et jusqu'où il faut le faire n'est en rien évident (surtout pour un noyau ou le critère performance est très important).
Tu peux faire un noyau en java, mais c'est lent et le code spécifique que tu as retiré en utilisant java, tu le retrouves dans java. Le gain est nul.
> D'autre part parce que le code de gestion de la VMM n'a pas un besoin fondamental de gerer des tables a 2 ou 3 indirections : il est essentiellement question d'etablir des traductions adresse virtuelle -> physique, pas de dire que l'entree 12 de la table de niveau 4 pointe sur la table a l'adresse physique 0x1234000, etc... Si la VMM pouvait se passer de ce genre de detail, ca serait quand meme plus elegant.
L'interface (externe) se passe de ce genre de détail (sauf pour quelques cas rarement utilisé). Donc la voie est libre pour implémenter différement la VMM où même faire une VMM totalement spécifique à ppc sans retoucher (ou peu) l'API externe.
Au final et pour être bien d'accord. Je ne vais pas dire les avantages ou inconvénient des techniques de telle ou telle vmm. Je n'ai pas les compétences. Ce qui m'"énerve" c'est de voir les gens parler d'_API_ en des définissants comme spécifiques à une architecture.
Ce que tu reproches à la vmm ici (et si j'ai bien compris) a du sens. Tu ne reproches pas l'API (externe) mais que la vmm "colle" que système qu'on retrouve sur les systèmes types x86 et que ce n'est pas forcement la bonne aproche pour toutes les architectures. Tu ne demandes pas que l'API (externe) soit encore plus neutre par rapport au architecture mais que son fonctionnement interne soit plus neutre et pas "optimisé" pour un type d'architecture.
Je n'ai pas de problème avec ça.