Journal Micro noyau

Posté par  .
Étiquettes : aucune
0
13
fév.
2004
Salut,

j'avais eu une petite idée pour linux (je suis surement pas le seul a l'avoir eu) en fait je pensais "transformer" linux en micro noyau
ou dans un mode mixte (ok mon driver qui a besoin de ne pas etre court-circuité et qui est "super" stable serait en mode noyau et un autre driver en mode utilisateur ...).

Je pense que déjà hacker le partie s'occupant des modules serait une bonne idée :) (les charger en mode utilisateur)
Puis pouvoir faire un hello worold serait pas mal ;)

C'est mon avis mais je pense qu'il est possible grace a cela d'avoir une meilleur stabilitée (un module qui plante serait fermer comme un bete programme), on pourrait avoir un système proche des translator de hurd :), ....

Qu'en pensez-vous ?

merci
  • # Re: Micro noyau

    Posté par  . Évalué à 2.

  • # Commentaire supprimé

    Posté par  . Évalué à 3.

    Ce commentaire a été supprimé par l’équipe de modération.

    • [^] # Re: Micro noyau

      Posté par  . Évalué à 0.

      lol Je l'avais oublié celui la ;)

      En fait corrigez moi si je dis une bétise dans la version 2.4 du noyau quand on branchait une webcam (j'ai oublié le nom de la marque) le noyau freezait ....

      Ca le fait pas trop je trouve surtout quand on entend les arguments linux est plus stable que windows etc ....

      C'est en partie pour ca ;)
      • [^] # Commentaire supprimé

        Posté par  . Évalué à 2.

        Ce commentaire a été supprimé par l’équipe de modération.

      • [^] # Re: Micro noyau

        Posté par  . Évalué à 1.

        Si un module est pas stable c'est pas un module pour un système linux a fortiori pour un utilisateur qui compare le système à Windows.
      • [^] # Re: Micro noyau

        Posté par  . Évalué à 1.

        la marque : philips
        le modele : jecplu
  • # Re: Micro noyau

    Posté par  . Évalué à 4.

    As-tu déjà entendu parler de User Mode Linux? http://usermodelinux.org/(...)
    D'une certaine façon, ça devrait te permettre d'implémenter une partie de ce que tu veux, à savoir mettre une partie du kernel en espace utilisateur.

    Sinon, transformer linux en micro-kernel, à part pour la beauté du geste, est un projet mort-né vu l'opposition historique de Linus vis à vis des micro-kernel.

    Autre chose, ce que tu veux faire, a peut-être déjà été fait avec le projet mklinux: http://www.mklinux.org/(...) . Ils ont peut-être besoin d'un codeur aventureux comme toi!
  • # drivers usermode

    Posté par  . Évalué à 1.

    c'est privilégier la sécurité au détriment des performances (un développeur Hurd m'a expliqué que les changements de contexte user/kernel étaient couteux avec les procs actuels)

    il existe deja des drivers en mode user: drivers pour modems adsl comme speedtouch et eci

    il y a aussi des modules qui sont mixtes comme netfilter ou linuxsecuritymodule, une partie du code étant exécutable en mode user ( je pense qu'on a la meme chose pour les modules drivers de xfree/dri )

    et surtout il y a Linux Userland FileSystem
    https://sourceforge.net/projects/lufs/(...)
  • # Re: Micro noyau

    Posté par  . Évalué à 1.

    Je pense que t'as bcp de boulot devant toi si tu as envie de transformer Linux en un micro-kernel de qualite acceptable.

    kernel et micro-kernel c'est pas vraiment le meme design, car t'as pas les memes contraintes.

    Bref, j'esperes pour toi que t'as rien de prevu pour les 3 prochaines annees, parce que tu vas etre occupe.
    • [^] # Re: Micro noyau

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

      Sans aller jusqu'au micro noyau, on pourrais peut être tenter d'introduire une protection de la mémoire (espace noyau et utilisateur) contre les modules propriétaires.
      Il faudrait ensuite introduire dans l'espace utilisateur des librairies qui seraient marquées comme "infectables" et qui feraient le lien entre les applications et les drivers (dans le cas de nvidia on pourrais mettre cet attribut sur les librairies OpenGL et le driver XFree86 (ça supposerais quand même d'exécuter les drivers de Xfree dans un espace délimité mais c'est faisable à mon avis)).

      Je crois que le problème serait surtout de permettre aux drivers proprio d'utiliser les fonctions du noyau, qui ne sont pas limitées dans leur espace d'application. Pour ce que j'en sais, les fonctions les plus bas niveau sont maintenant gérée par une couche d'abstraction. Peut être que se contenter de n'autoriser que l'appel dans cette couche des fonctions s'appliquant au hardware que le pilote dit gérer permettrait d'assurer cette protection ? Il resterait probablement une ou deux fonctions génériques et utilisées par tous les pilotes, mais appliquer sur ces quelques fonctions un contrôle de sécurité pour les appels des modules proprios me parait déjà moins impossible et surtout moins couteux en terme de performances.
      Surtout que maintenant le noyeau peut préempter voir forcer le déchargement des maichants pilotes.

      Enfin, je dis ça, mais j'ai jamais touché au noyo... c'est juste mon imagination fertile de cette heure là du matin -_^.
      • [^] # Re: Micro noyau

        Posté par  . Évalué à 1.

        j'ai bien peur que tout ça soit à peu près aussi couteux que les changements de contexte user/kernel quand on utilise un process normal en mode user.
        Dans ce cas autant utiliser des modules qui se contentent de faire faire tout le travail par des process normaux du userland, et ça tu peux le faire tout de suite dans Linux sans aucun problème (si tu acceptes les ralentissements inévitables).

        Maintenant si ce que tu veux c'est système libre compatible POSIX (et donc avec l'essentiel des APIs Linux) basé sur un micronoyau, Hurd est là pour ça !
        • [^] # Re: Micro noyau

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

          j'ai bien peur que tout ça soit à peu près aussi coûteux que les changements de contexte user/kernel quand on utilise un process normal en mode user.

          En fait ce que je propose ça serait des sortes de processus privilégiés, qui auraient la possibilité d'accéder au hardware mais n'utiliseraient pas la mémoire virtuelle et toutes ces choses, pour des raisons de performances.
          Pour ce que je connais du système, et en supposant que les mécanismes hardware de protection mémoire soient suffisement flexibles, ça consisterait à mettre en place un espace "kernel", un "espace utilisateur", un espace "kernel bis" et un espace "utilisateur bis".
          L'espace "kernel bis" serait l'espace kernel normal sauf que les mécanisme de protection mémoire seraient activé. L'espace "utilisateur bis" serait la partie de l'espace mémoire auquel les membres de "kernel bis" auraient accès.
          En cas d'IRQ, au moment de choisir le handler, on activerais la protection mémoire suivant que l'appel est destiné à "kernel bis" ou non.
          On perdrais quelque chose comme un cycle ou deux par appel système libres (tester un flag) et cinq cycles par appel système pas libre (tester le flag et activer la protection).

          Je précise que les ordres de grandeur son le fruit de mon imagination, qu'il est 3:50 et que je ne connais pas bien la manière dont la protection mémoire est implantée sur les x86. Ceci dit, à la réflection je crois qu'elle consiste à mettre en place 3 anneaux dans lesquels les membres des anneaux supérieurs ont accès à tous les anneaux inférieurs. Ça permettrait pas de protéger l'espace utilisateurs des modules propriétaires, donc aucun intérêt -_-. Mais je suis pas sûr, et je sais pas ce qu'il en est sur les autres architectures.
        • [^] # Re: Micro noyau

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

          Hurd est là pour ça !
          _Le_ Hurd! Mais que fais la police??!

          Sinon, http://hurd.gnufans.org(...) est un bon point de départ :) Ensuite y'a des liens vers GNUMach, L4 etc

Suivre le flux des commentaires

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