• # Billet source

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 22 juillet 2023 à 16:21.

    L'idée générale : how to use the driver of another OS in order to run your apps on Redox OS ?

  • # Contexte

    Posté par  . Évalué à 2.

    Redox is a Unix-like Operating System written in Rust, aiming to bring the innovations of Rust to a modern microkernel and full set of applications.
    Inspired by Plan 9, Minix, BSD and Linux
    Implemented in Rust
    Microkernel Design
    Includes optional GUI - Orbital
    Supports Rust Standard Library
    MIT Licensed
    Drivers run in Userspace
    Includes common Unix commands
    Custom libc written in Rust (relibc)

    • [^] # Re: Contexte

      Posté par  (site web personnel) . Évalué à 4. Dernière modification le 23 juillet 2023 à 11:20.

      Drivers run in Userspace

      Une idée des raisons de ce choix d'ailleurs ?

      • [^] # Re: Contexte

        Posté par  (Mastodon) . Évalué à 4.

        Drivers run in Userspace

        Une idée des raisons de ce choix d'ailleurs ?

        Que si un driver a un souci (plantage, bloquage…), il peut être immédiatement relancé sans tout un pataquès dans le noyau ?

        • [^] # Re: Contexte

          Posté par  (site web personnel) . Évalué à 4.

          Ok, et une raison que d'autres ne fassent pas ce choix ?

          • [^] # Re: Contexte

            Posté par  (site web personnel) . Évalué à 10.

            Faut revoir le débat Tanenbaum vs Torvalds au début du noyau Linux pour avoir les arguments de l'époque qui ont peut changé depuis.

            En gros ce choix de conception fait partie des noyaux dits micro-noyaux (Hurd, Minix, Redox OS, autres) et ceux dits monolithiques (Linux, BSD, etc.). Windows et macOS ont clairement une approche hybride en mettant le maximum en espace utilisateur mais gardant malgré tout pour des raisons de performances certaines choses dans l'espace noyau.

            Le nerf de la guerre c'est donc fiabilité contre performance. Car le passage de l'espace utilisateur à espace noyau est coûteux en temps (car le processeur doit faire certaines actions, tu peux perdre en cache des données, etc.) et y passer tous les pilotes en espace utilisateur a donc un impact significatif à cet égard. Cela augmente aussi la nécessité d'échanger des messages entre les pilotes et le reste du noyau ce qui ajoute un peu de complexité.

            Mais l'avantage c'est que si le pilote crashe (corruption mémoire ou autre), cela n'affectera pas à priori le reste du noyau qui pourra le relancer si nécessaire. Dans le cas d'un noyau monolithique comme Linux ton ordinateur est souvent bon à redémarrer suite à un kernel panic généré dans ce cas.

            30 ans après on voit que les approches absolutistes ont échoué. Les micro-noyaux purs sont peu répandus et les approches hybrides semblent privilégiés. C'est ce qui permet par exemple à Windows de relancer le pilote graphique quand il plante ce qui peut arriver, ces pilotes étant très gros et complexes un crash peut arriver de temps en temps.

            • [^] # Re: Contexte

              Posté par  (site web personnel) . Évalué à 3.

              Top, merci !

            • [^] # Re: Contexte

              Posté par  . Évalué à 0.

              30 ans après on voit que les approches absolutistes ont échoué.

              Tu trouve que linux a échoué ?

              https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

            • [^] # Re: Contexte

              Posté par  (site web personnel) . Évalué à 2.

              Est-ce que l’approche monolithique de Linux n’impose pas, au moins partiellement, des pilotes en gpl, et pérennes ? Le premier dans la mesure où ils sont inclus dans du code en gpl, et le second parce qu’ils sont inclus dans le noyau. Pour certains ces conséquences de l’approche monolithique de Linux ne sont-elles pas un vrai atout : pas de matériel qui cesse définitivement de fonctionner pour cause de politique commercial ?

              « IRAFURORBREVISESTANIMUMREGEQUINISIPARETIMPERAT » — Odes — Horace

              • [^] # Re: Contexte

                Posté par  (site web personnel, Mastodon) . Évalué à 2.

                Question de point de vue. L'approche de Linux est qu'ils n'hésitent pas à modifier les interfaces entre le noyau et les pilotes, donc un pilote de périphérique qui veut survivre longtemps a tout intérêt à être inclus dans le noyau et à se trouver un mainteneur pour faire les mises à jour.

                Une autre approche serait d'avoir une interface stable entre le lyau et les pilotes, et dans ce cas, le pilote pourrait etre écrit une bonne fois pour toutes et nécessiter peu de maintenance. Peut-être que les entreprises construisant du matériel arriveraient mieux à maintenir leurs pilotes à jour dans ce cas, et sans avoir à publier leur code source (il y a une certaine culture du secret sur le sujet…)

                Les deux modèles peuvent se défendre, mais dans tous les cas, c'est toujours mieux d'avoir le code source sous une license qui permet d'assurer soi-même la maintenance

                • [^] # Re: Contexte

                  Posté par  (site web personnel) . Évalué à 6. Dernière modification le 25 juillet 2023 à 11:24.

                  Si les constructeurs pouvaient aussi se calmer sur la complexité et utiliser des standards…

                  Quelques exemples :

                  • pour les manettes, sur USB on a les variantes DirectInput/Xinput/HID et une variante par console. En sans fil, on a le Bluetooth qui ne fait pas semblant de marcher, les dongles 2.4G où chaque constructeur a son standard et une variante par console => ils ne peuvent pas se mettre d'accord pour gérer quelques axes et boutons ? ;
                  • pour les imprimantes, c'est le chaos absolu, là où imprimer devrait se résumer à envoyer un pdf + quelques options ;
                  • HDMI dont le protocole de négociation est tellement complexe qu'il faut plusieurs secondes pour caler l'affichage avec de nombreux bugs, là où un bon vieux VGA marchait immédiatement.

                  Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

                  • [^] # Re: Contexte

                    Posté par  (Mastodon) . Évalué à 3.

                    Displayport est assez bien fait je crois comme protocole/standard

            • [^] # Re: Contexte

              Posté par  (site web personnel, Mastodon) . Évalué à 2.

              Dans les systèmes à micronoyaux il faut quand même citer Fuchsia chez Google, même si il n'est pas très utilisé en dehors de l'entreprise.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.