Bonjour,
En lisant l'article sur Hurd dans le dernier GNU/Linux Mag, je suis tombé sur un truc du tonnerre : Les traducteurs ! Pour ceux qui, comme moi il y a peu, ne connaissent pas, je vais tenter de résumer.
Avec le Hurd, un traducteur est un process qui s'intercale entre l'utilisateur et "un fichier". C'est à dire que lorsqu'on va accéder à ce fichier (read(), cat ...) on aura en fait les entrées/sorties du process. Et cela fonctionne pour tout fichier : un point de montage, un periph (/dev/...) ou un simple fichier texte et en plus en espace utilisateur.
Pour des explications plus claires, je vous renvoie la : [1]
Il se trouve que c'est LA solution à un problème que j'ai récemment rencontré.
[mavie]
Je voulais avoir une playlist avec les dernières vidéos du vrai journal de C+, bien sur actualisée chaque semaine. En plus je ne voulais ni cron ni démon car c'est sur une box de salon.
[/mavie]
J'ai résolu ce problème avec un script cgi sur le serveur d'une autre machine.
J'avais aussi envisagé un tube nommé alimenté par un démon.
D'ou ma question : comment implémenter un tel mécanisme sous GNU/Linux ? Suis-je passé à coté de quelque chose ou est-ce un gros avantage de Hurd ?
[1] http://www.hurdfr.org/index.php?page=pages/doc/traducteur(...)
Journal Traducteurs : LeHurd vs Linux !
17
avr.
2005
# PS
Posté par jjl (site web personnel) . Évalué à 4.
... non je n'installerai pas Hurd même si c'est sans doute très enrichissant.
D'une part ma carte sat. n'est pas supportée et en plus je ne veux pas casser ma box de salon !
Tant que ca marche ...
# FUSE
Posté par fabb . Évalué à 10.
Oui :
Filesystem in Userspace
http://fuse.sourceforge.net/(...)
[^] # Re: FUSE
Posté par jjl (site web personnel) . Évalué à 3.
En plus y'a même un binding perl http://search.cpan.org/~dpavlin/Fuse-0.05/Fuse.pm(...) (et Python aussi)
Merci, je plussoie dans la joie !
[^] # Re: FUSE
Posté par Krunch (site web personnel) . Évalué à 3.
http://perlfs.sf.net/(...)
Sinon tu peux être intéressé dans 9P.
http://cm.bell-labs.com/magic/man2html/5/0intro(...)
http://v9fs.sf.net/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: FUSE
Posté par djrom . Évalué à 10.
D'une part, il y a beaucoup de problèmes quant à la sémantique que tu obtiens avec FUSE par rapport aux permissions (voir le thread suivant de la LKML: http://thread.gmane.org/gmane.linux.kernel/295707(...) )
Ensuite, les performances ne suivent pas du tout avec FUSE, parce que c'est un hack assez intelligent autour du noyau, mais que ça reste un hack. Le noyau n'étant pas conçu dans ses principes même pour faire ça, le coup en terme de performances est assez prohibitif.
Un autre problème est une question de sécurité/stabilité: rajouter FUSE, c'est rajouter un module qui tourne en espace noyau, module faisant un tas d'interactions complexes avec l'espace utilisateur, et donc étant sujet à bug(s). Si ton FUSE crash, ton noyau est par terre. Si une personne trouve une faille de sécurité dans FUSE, pouf il a un exploit local (et même peut-être distant) pour faire tout ce qu'il veux.
Ca fait un bout de temps qu'on peut voir sur Internet FUSE cité comme un exemple de "le Hurd ça sert à rien, on peut déjà tout faire sous Linux". Mais c'est pas vraiment la même chose. Les translators font parti de la base même du fonctionnement de Hurd, avec tout ce que ça apporte comme avantages en terme de performances, de scalabilité (un mot meilleur ?), de sécurité, ... FUSE offre un équivalent en terme de fonctionnalités pures, mais pas avec la même facilité/élégance. On pourrait dire que comparer FUSE aux translators du Hurd en les présentant comme équivalents, c'est comme utiliser Cygwin pour dire "Linux, ça sert à rien, on peut faire tourner ce qu'on veut comme programme UNIX sous Windows". Dans un cas comme dans l'autre, les fonctionnalités sont les mêmes, mais pas avec le même confort.
Cela dit, 'me faites pas dire ce que j'ai pas dit: j'ai pas affirmé que le Hurd était utilisable, génial, révolutionnaire, ou quoi que ce soit. (c'qu'il faut pas faire pour couper l'herbe sous le pied des trolls :))
[^] # Re: FUSE
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
"Passage à l'échelle".
[^] # Re: FUSE
Posté par kd . Évalué à 5.
[^] # Re: FUSE
Posté par Dring . Évalué à 1.
Cela étant dit, je n'ai pas de meilleur mot...
[^] # Re: FUSE
Posté par M . Évalué à 3.
- pas de methode seek, tout passe par un read, du coup si on veut faire un truc un peu optimiser (c'est deja assez lent comme ca), une des premiere chose qu'on fait dans le read c'est de regarder si on a fait un seek
- pas moyen de preciser forcer un blocksize pour l'ecriture/lecture. Du coup on doit passer par des buffers intermediares/se prendre la tete qd on commence/fini au milieu d'un block
- pas de reel gestion de cache : par default fuse lit par page, du coup on lit beaucoup, on attend que le buffer se vide, on relit beaucoup, ce qui peut parfois entraine des delai lors de la lecture sur des medias lent.
Je dis pas que soit doit forcement etre implementer dans le noyau, mais au moins la lib fuse pourrait proposer des solutions generiques pour eviter d'avoir a coder plus de glue generique que le reste...
[^] # Re: FUSE
Posté par Pinaraf . Évalué à 2.
j'écrivais pour voir un peu les capacités de fuse en python une tentative de FS lié à une base de données sqlite.
Connement j'ai fait une faute de frappe dans une requête sql... => exception déclenchée non capturée
Pour remonter mon système de fichier, la seule solution a été le redémarrage !
Donc oui fuse c'est bien, mais c'est très contraignant, t'as pas droit à l'erreur sinon reboot ! Donc le top pour faire un fs avec fuse c'est encore de tester dans un UML ou autre pseudo émulateur ... vive la légèreté !
(Note : je sais que c'est ma faute pour l'exception non capturée, j'aurais du faire gaffe)
[^] # Re: FUSE
Posté par fabb . Évalué à 1.
T'as peut-être un problème de mise au point de FUSE (qui est récent).
Je ne vois pas pourquoi si FUSE est au point, il nécessiterait un reboot en cas de problème.
[^] # Re: FUSE
Posté par Pinaraf . Évalué à 2.
Néanmoins, mon exemple montre tout de même que fuse reste un mix kernel / user space, alors que les translators ont l'avantage d'être 100% user space.
Quoiqu'ils fassent, fuse ne pourra pas atteindre les capacités des translators, à moins que linux ne devienne un micro-noyau, ce qui me paraît franchement impossible
[^] # Re: FUSE
Posté par fabb . Évalué à 1.
Je ne mets pas en cause la véracité de ton "témoinage. Mais FUSE n'est toujours pas en upstream par exemple.
> alors que les translators ont l'avantage d'être 100% user space.
Là, tu rèves. Si ne n'était que du user space alors il pourrait aussi toujours sous Linux. Non ?
Hurd (le noyau) fournit un support pour les translators. Ce support fontionne en mode noyau. C'est obligé.
[^] # Re: FUSE
Posté par Pinaraf . Évalué à 2.
Hurd (le noyau) fournit un support pour les translators. Ce support fontionne en mode noyau. C'est obligé.
Non, sous linux il y a dans le noyau la bête noire des mecs de Reiser4 : la VFS, qui les empêche d'avoir 10000 trucs super classes dans leur reiser4...
Pour les translateurs, dans Hurd à base de GNU Mach, y'a une partie kernel space apparemment... mea culpa
Par contre pour le futur Hurd/L4, vu que même les drivers seront en user space, je pense que tout sera en user space !
Enfin je connais trop peu hurd, je ne m'aventurerai pas dans des domaines que je connais mal... Si manuel passe, il pourrait te l'expliquer très bien
[^] # Re: FUSE
Posté par fabb . Évalué à 1.
Sinon, c'est un exemple parmis d'autre, ça veut dire que le noyau ne fait plus les contrôles de sécurité et que n'importe quel programme utilisateur peut faire les contrôles de sécurité.
Ça te plais comme type de fonctionnement ?
Pas moi.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.