Concernant LUFS :
- ça ne risque pas d'être intégré un jour ou l'autre au noyau, l'API est très différente et en C++ (comme l'implémentation d'ailleurs).
- c'est pas vraiment trivial d'implémenter un nouveau fs dedans (nécessité de recompiler le tout... en tout cas à l'époque où j'avais voulu faire un truc dessus)
- La dernière version date du 30 octobre 2003. Je considère le projet comme abandonné devant un autre plus prometteur nommé fuse.
Alors, fuse
- est en C
- semble plus clean (en tout cas pour ce que j'en ai fait) et est à coup sûr plus actif
- pourrait être bientôt intégré au noyau Linux (en tout cas c'est ce que j'ai lu...).
- a depuis peu un tout nouveau site tout beau : http://fuse.sourceforge.net/
On peut se demander pourquoi Linux n'utilise pas ce genre de truc depuis 14 ans, ça permet de décharger _énormément_ le noyau et donc les efforts du programmeur puisqu'on peut désormais utiliser les bibliothèques partagées (un exemple : la libsmbclient permet de faire un fs smb/CIFS stable et complet en quelques lignes de code plutôt que d'utiliser l'immonde smbfs du noyau !). Des gros fs comme coda/intermezzo gagneraient également énormément à être implémentés de cette manière...
Petite question hors-sujet pour ceux qui connaissent bien les arcanes du hurd ou de la conception d'OS : pourquoi vouloir absolument scinder l'OS en de multiples processus serveurs ayant chacuns leur espaces d'adressages distincts ? OK pour la sécurité/sûreté mais ce que je veux dire c'est que ça pénalise tout de même pas mal les performances (changements de contextes, cache invalidé...) et il y a peut-être d'autres moyens de virer du code hors du noyau sans en passer par là. N'y aurait-il pas par ex. moyen de faire que (si l'utilisateur le configure ainsi) le hurd puisse utiliser davantage le concept de bibliothèques partagées (i.e. des bouts de code mappés dans l'espace d'adressage de l'appli en cours) plutôt que de "serveurs" ? Par exemple, on pourrait à mon avis fort bien imaginer que toute la pile IP, le firewalling, etc soit implémenté dans une (ou des) DLLs, idem pour les pilotes de périphériques, etc. Il me semble (mais je ne suis pas sûr, qqun peut confirmer ?) que c'est un peu l'idée des exokernels, et qu'apparemment ça booste bien les perfs et ça rassemble le meilleur des deux mondes (système rapide, modulaire et tout petit noyau).
[^] # Re: heeeuu
Posté par karteum59 (site web personnel) . En réponse à la dépêche Hurd : nouvelle version de Debian GNU/Hurd et avancée du port sur L4. Évalué à 6.
- ça ne risque pas d'être intégré un jour ou l'autre au noyau, l'API est très différente et en C++ (comme l'implémentation d'ailleurs).
- c'est pas vraiment trivial d'implémenter un nouveau fs dedans (nécessité de recompiler le tout... en tout cas à l'époque où j'avais voulu faire un truc dessus)
- La dernière version date du 30 octobre 2003. Je considère le projet comme abandonné devant un autre plus prometteur nommé fuse.
Alors, fuse
- est en C
- semble plus clean (en tout cas pour ce que j'en ai fait) et est à coup sûr plus actif
- pourrait être bientôt intégré au noyau Linux (en tout cas c'est ce que j'ai lu...).
- a depuis peu un tout nouveau site tout beau : http://fuse.sourceforge.net/
On peut se demander pourquoi Linux n'utilise pas ce genre de truc depuis 14 ans, ça permet de décharger _énormément_ le noyau et donc les efforts du programmeur puisqu'on peut désormais utiliser les bibliothèques partagées (un exemple : la libsmbclient permet de faire un fs smb/CIFS stable et complet en quelques lignes de code plutôt que d'utiliser l'immonde smbfs du noyau !). Des gros fs comme coda/intermezzo gagneraient également énormément à être implémentés de cette manière...
Petite question hors-sujet pour ceux qui connaissent bien les arcanes du hurd ou de la conception d'OS : pourquoi vouloir absolument scinder l'OS en de multiples processus serveurs ayant chacuns leur espaces d'adressages distincts ? OK pour la sécurité/sûreté mais ce que je veux dire c'est que ça pénalise tout de même pas mal les performances (changements de contextes, cache invalidé...) et il y a peut-être d'autres moyens de virer du code hors du noyau sans en passer par là. N'y aurait-il pas par ex. moyen de faire que (si l'utilisateur le configure ainsi) le hurd puisse utiliser davantage le concept de bibliothèques partagées (i.e. des bouts de code mappés dans l'espace d'adressage de l'appli en cours) plutôt que de "serveurs" ? Par exemple, on pourrait à mon avis fort bien imaginer que toute la pile IP, le firewalling, etc soit implémenté dans une (ou des) DLLs, idem pour les pilotes de périphériques, etc. Il me semble (mais je ne suis pas sûr, qqun peut confirmer ?) que c'est un peu l'idée des exokernels, et qu'apparemment ça booste bien les perfs et ça rassemble le meilleur des deux mondes (système rapide, modulaire et tout petit noyau).