En fait, la mémoire partagée sera implémentée dans l'avenir; cependant, comme chacun sait, celle-ci entraîne la création de canaux de communication cachés très importants dans le système. Pour résoudre ce problème, l'administrateur aura le choix entre :
S'il s'appelle super-parano-man, reconfigurer le noyau pour désactiver cette fonctionnalité (après tout, je n'ai pas créé un noyau à patchage dynamique pour rien!);
Si c'est juste parano-man ou un de ses acolytes, il pourra installer les mêmes bibliothèques plusieurs fois, et choisir quels programmes accèdent à quels exemplaires des bibliothèques. Cela donnera un comportement proche de celui des compartiments de Solaris.
d'ailleurs, dans le meme ordre d'idée, comment se passe la communication inter-programmes ?
Cela dépend du mécanisme. Si c'est un simple pipe, pas de problème : il est créé classiquement par le père par pipe(2) avant le fork(2), puis conservé par les fils après l'execve(2). Si c'est un pipe nommé ou une socket du domaine UNIX, il faut recourir à un lien matériel vers le fichier en question pour lui permettre d'apparaître dans les divers chroots. A titre d'exemple, c'est déjà ce qui est fait pour permettre la communication entre init et telinit du paquetage sysvinit.
(Les sockets anonymes du domaine UNIX, qui ne sont au fond qu'une extension Linux, ne seront tout simplement pas implémentées.)
En ce qui concerne les segments de mémoire partagés, et les autres IPCs system-V, je reconnais que je n'ai pas encore décidé de la façon dont j'allais procéder à leur isolement, mais j'emploierai certainement une méthode de type "espace de noms" comme sous Linux (CLONE_NEWIPC); de même pour les signaux.
[^] # Re: 0 day
Posté par Emmanuel Colbus . En réponse au journal Annonce : Manux 0.0.4. Évalué à 4.
Pas de problème.
En fait, la mémoire partagée sera implémentée dans l'avenir; cependant, comme chacun sait, celle-ci entraîne la création de canaux de communication cachés très importants dans le système. Pour résoudre ce problème, l'administrateur aura le choix entre :
Cela dépend du mécanisme. Si c'est un simple pipe, pas de problème : il est créé classiquement par le père par pipe(2) avant le fork(2), puis conservé par les fils après l'execve(2). Si c'est un pipe nommé ou une socket du domaine UNIX, il faut recourir à un lien matériel vers le fichier en question pour lui permettre d'apparaître dans les divers chroots. A titre d'exemple, c'est déjà ce qui est fait pour permettre la communication entre init et telinit du paquetage sysvinit.
(Les sockets anonymes du domaine UNIX, qui ne sont au fond qu'une extension Linux, ne seront tout simplement pas implémentées.)
En ce qui concerne les segments de mémoire partagés, et les autres IPCs system-V, je reconnais que je n'ai pas encore décidé de la façon dont j'allais procéder à leur isolement, mais j'emploierai certainement une méthode de type "espace de noms" comme sous Linux (CLONE_NEWIPC); de même pour les signaux.