En relisant mon premier post, je me rends compte que je n'étais pas clair, en fait...
Je suis tout à fait d'accord avec toi, la seule méthode pour faire ce qu'il veut, c'est la virtualisation. Je notais juste qu'en dehors de Xen et Qemu, qui sont des technologies de virtualisation "génériques" (peut-on dire "portables" dans cette situation ?), il existait aussi une techno "pure Linux" comme UML qui faisait ce qu'il veut (faire tourner un Linux au-desus d'un Linux).
D'ailleurs, même si le problème (fondamental) de l'accès concurrent aux ressources par les 2 (ou n) noyaux ne se posait pas, et UML mis et part, il resterait que le noyau Linux est fait pour tourner directement au-dessus du matériel, pas en tant que processus au-dessus d'un autre noyau (ou même en thread supplémentaire d'un noyau existant).
D'où les différentes solutions qui existent déjà:
- patcher Linux pour qu'il tourne comme un processus utilisateur au-dessus de Linux (UML);
- créer une plate-forme intermédiaire sur laquelle on pourrait faire fonctionner parallèlement plusieurs noyaux adaptés à cette nouvelle plate-forme (Xen);
- émuler une architecture matérielle en mode utilisateur sur laquelle un noyau non patché peut tourner (Qemu, et plein d'autres).
Il est possible que d'autres solutions existent (quoiqu'à première vue je ne vois pas d'autres méthodes que les 3 que j'ai citées), mais je suis d'accord que chroot/kexec ne semble pas pouvoir y arriver.
[^] # Re: tu y es presque ... à coté
Posté par alf . En réponse au message Lancer deux (ou plusieurs) distributions. Évalué à 1.
Je suis tout à fait d'accord avec toi, la seule méthode pour faire ce qu'il veut, c'est la virtualisation. Je notais juste qu'en dehors de Xen et Qemu, qui sont des technologies de virtualisation "génériques" (peut-on dire "portables" dans cette situation ?), il existait aussi une techno "pure Linux" comme UML qui faisait ce qu'il veut (faire tourner un Linux au-desus d'un Linux).
D'ailleurs, même si le problème (fondamental) de l'accès concurrent aux ressources par les 2 (ou n) noyaux ne se posait pas, et UML mis et part, il resterait que le noyau Linux est fait pour tourner directement au-dessus du matériel, pas en tant que processus au-dessus d'un autre noyau (ou même en thread supplémentaire d'un noyau existant).
D'où les différentes solutions qui existent déjà:
- patcher Linux pour qu'il tourne comme un processus utilisateur au-dessus de Linux (UML);
- créer une plate-forme intermédiaire sur laquelle on pourrait faire fonctionner parallèlement plusieurs noyaux adaptés à cette nouvelle plate-forme (Xen);
- émuler une architecture matérielle en mode utilisateur sur laquelle un noyau non patché peut tourner (Qemu, et plein d'autres).
Il est possible que d'autres solutions existent (quoiqu'à première vue je ne vois pas d'autres méthodes que les 3 que j'ai citées), mais je suis d'accord que chroot/kexec ne semble pas pouvoir y arriver.