"ZebX" a écrit dans le message de news: 432fd831$0$17461$
Bonjour, Bonjour,
Le logiciel gamin, clone de FAM, est utilisé par quel genre de logiciel. pas clone, remplaçant.
FAM utilise dnotify, Gamin c'est Inotify (ou l'inverse ?) depuis la 2.6.12 (13?)
Pour les deux, c'est un moniteur d'altération de fichier... c'est pour que tous les softs qui utilisent fam/gamin soit au courant du moindre changement sur un fichier/répertoire sur le disque => genre actualise automatiquement une arborescence lors du moindre changement
C'est utilisé dans konqueror entre autre
Emmanuel.
"ZebX" <zebx@zebx.zebx> a écrit dans le message de news:
432fd831$0$17461$626a14ce@news.free.fr...
Bonjour,
Bonjour,
Le logiciel gamin, clone de FAM, est utilisé par quel genre de logiciel.
pas clone, remplaçant.
FAM utilise dnotify, Gamin c'est Inotify (ou l'inverse ?) depuis la 2.6.12
(13?)
Pour les deux, c'est un moniteur d'altération de fichier...
c'est pour que tous les softs qui utilisent fam/gamin soit au courant du
moindre changement sur un fichier/répertoire sur le disque
=> genre actualise automatiquement une arborescence lors du moindre
changement
"ZebX" a écrit dans le message de news: 432fd831$0$17461$
Bonjour, Bonjour,
Le logiciel gamin, clone de FAM, est utilisé par quel genre de logiciel. pas clone, remplaçant.
FAM utilise dnotify, Gamin c'est Inotify (ou l'inverse ?) depuis la 2.6.12 (13?)
Pour les deux, c'est un moniteur d'altération de fichier... c'est pour que tous les softs qui utilisent fam/gamin soit au courant du moindre changement sur un fichier/répertoire sur le disque => genre actualise automatiquement une arborescence lors du moindre changement
C'est utilisé dans konqueror entre autre
Emmanuel.
lhabert
"manu" :
Pour les deux, c'est un moniteur d'altération de fichier... c'est pour que tous les softs qui utilisent fam/gamin soit au courant du moindre changement sur un fichier/répertoire sur le disque => genre actualise automatiquement une arborescence lors du moindre changement
Un ami m'a raconté une histoire d'horreur où il s'était retrouvé avec ce truc lancé à l'insu de son plein gré, qui lui bouffait tout son CPU lors d'un calcul qui pondait des résultats progressivement dans un fichier (et donc le fichier augmentait de taille, et fam passait son temps à se faire notifier par le noyau).
"manu" :
Pour les deux, c'est un moniteur d'altération de fichier...
c'est pour que tous les softs qui utilisent fam/gamin soit au courant du
moindre changement sur un fichier/répertoire sur le disque
=> genre actualise automatiquement une arborescence lors du moindre
changement
Un ami m'a raconté une histoire d'horreur où il s'était retrouvé avec ce
truc lancé à l'insu de son plein gré, qui lui bouffait tout son CPU lors
d'un calcul qui pondait des résultats progressivement dans un fichier (et
donc le fichier augmentait de taille, et fam passait son temps à se faire
notifier par le noyau).
Pour les deux, c'est un moniteur d'altération de fichier... c'est pour que tous les softs qui utilisent fam/gamin soit au courant du moindre changement sur un fichier/répertoire sur le disque => genre actualise automatiquement une arborescence lors du moindre changement
Un ami m'a raconté une histoire d'horreur où il s'était retrouvé avec ce truc lancé à l'insu de son plein gré, qui lui bouffait tout son CPU lors d'un calcul qui pondait des résultats progressivement dans un fichier (et donc le fichier augmentait de taille, et fam passait son temps à se faire notifier par le noyau).
Nicolas George
"manu" wrote in message <43300d96$0$31684$:
Pour les deux, c'est un moniteur d'altération de fichier... c'est pour que tous les softs qui utilisent fam/gamin soit au courant du moindre changement sur un fichier/répertoire sur le disque => genre actualise automatiquement une arborescence lors du moindre changement
Soit dit en passant, c'est inutile pour un Linux >= 2.4, puisqu'il y a F_NOTIFY.
"manu" wrote in message <43300d96$0$31684$626a14ce@news.free.fr>:
Pour les deux, c'est un moniteur d'altération de fichier...
c'est pour que tous les softs qui utilisent fam/gamin soit au courant du
moindre changement sur un fichier/répertoire sur le disque
=> genre actualise automatiquement une arborescence lors du moindre
changement
Soit dit en passant, c'est inutile pour un Linux >= 2.4, puisqu'il y a
F_NOTIFY.
Pour les deux, c'est un moniteur d'altération de fichier... c'est pour que tous les softs qui utilisent fam/gamin soit au courant du moindre changement sur un fichier/répertoire sur le disque => genre actualise automatiquement une arborescence lors du moindre changement
Soit dit en passant, c'est inutile pour un Linux >= 2.4, puisqu'il y a F_NOTIFY.
ZebX
Soit dit en passant, c'est inutile pour un Linux >= 2.4, puisqu'il y a F_NOTIFY.
:) C'est la question sous-jacente.
Dans mon cas, gamin s'est accroché sur un répertoire samba monté en autofs, alors qu'il n'est pas modifié. Résultat, le répertoire ne se démonte pas à l'issu du timeout.
Je suis en 2.6.10. Puis je supprimer le gamin sans risque, voir sans conséquence ?
-- ZebX - Mécano-boucher
Soit dit en passant, c'est inutile pour un Linux >= 2.4, puisqu'il y a
F_NOTIFY.
:) C'est la question sous-jacente.
Dans mon cas, gamin s'est accroché sur un répertoire samba monté en
autofs, alors qu'il n'est pas modifié.
Résultat, le répertoire ne se démonte pas à l'issu du timeout.
Je suis en 2.6.10. Puis je supprimer le gamin sans risque, voir sans
conséquence ?
Soit dit en passant, c'est inutile pour un Linux >= 2.4, puisqu'il y a F_NOTIFY.
:) C'est la question sous-jacente.
Dans mon cas, gamin s'est accroché sur un répertoire samba monté en autofs, alors qu'il n'est pas modifié. Résultat, le répertoire ne se démonte pas à l'issu du timeout.
Je suis en 2.6.10. Puis je supprimer le gamin sans risque, voir sans conséquence ?
-- ZebX - Mécano-boucher
TiChou
Dans le message <news:433015ca$0$8428$, *ZebX* tapota sur f.c.o.l.configuration :
Puis je supprimer le gamin sans risque, voir sans conséquence ?
Que dit le code civil et pénal à ce sujet ?
-- TiChou
Dans le message <news:433015ca$0$8428$626a14ce@news.free.fr>,
*ZebX* tapota sur f.c.o.l.configuration :
Puis je supprimer le gamin sans risque, voir sans conséquence ?
Je reformule : "C'est la question sous-jacente" à "Le logiciel gamin, clone de FAM, est utilisé par quel genre de logiciel ?"
Autrement dit, a quoi sert il réellement (= pas en théorie) et peut il donc être supprimé sans risque ?
Je détaille mon raisonnement : Sur le site de l'auteur, il indique des pb possibles lors des umount de répertoires. Il donne un exemple de fichier de paramétrage pour corriger le tout. Dans ce fichier, j'ai cru comprendre qu'on délègue la surveillance des répertoires montés au noyau. Donc, si le noyau peut surveiller les changements à quoi sert gamin ? Si c'est juste pour avertir konqueror et nautilus d'un changement plus rapidement que le noyau, c'est limité.
-- ZebX - Mécano-boucher
ZebX wrote in message <433015ca$0$8428$626a14ce@news.free.fr>:
:) C'est la question sous-jacente.
Quelle question ? Il n'y avait pas de question.
Je reformule : "C'est la question sous-jacente" à "Le logiciel gamin,
clone de FAM, est utilisé par quel genre de logiciel ?"
Autrement dit, a quoi sert il réellement (= pas en théorie) et peut il
donc être supprimé sans risque ?
Je détaille mon raisonnement :
Sur le site de l'auteur, il indique des pb possibles lors des umount de
répertoires. Il donne un exemple de fichier de paramétrage pour corriger
le tout. Dans ce fichier, j'ai cru comprendre qu'on délègue la
surveillance des répertoires montés au noyau.
Donc, si le noyau peut surveiller les changements à quoi sert gamin ?
Si c'est juste pour avertir konqueror et nautilus d'un changement plus
rapidement que le noyau, c'est limité.
Je reformule : "C'est la question sous-jacente" à "Le logiciel gamin, clone de FAM, est utilisé par quel genre de logiciel ?"
Autrement dit, a quoi sert il réellement (= pas en théorie) et peut il donc être supprimé sans risque ?
Je détaille mon raisonnement : Sur le site de l'auteur, il indique des pb possibles lors des umount de répertoires. Il donne un exemple de fichier de paramétrage pour corriger le tout. Dans ce fichier, j'ai cru comprendre qu'on délègue la surveillance des répertoires montés au noyau. Donc, si le noyau peut surveiller les changements à quoi sert gamin ? Si c'est juste pour avertir konqueror et nautilus d'un changement plus rapidement que le noyau, c'est limité.
Donc, si le noyau peut surveiller les changements à quoi sert gamin ? Si c'est juste pour avertir konqueror et nautilus d'un changement plus rapidement que le noyau, c'est limité.
La notification de la part du noyau, c'est quelque chose d'assez récent sous linux, et pas du tout standard. (Il y a-t-il d'autres unix qui ont ça?) Dans les cas où le noyau ne le supporte pas, il faut bien se démerder avec du polling. Si plusieurs programment pollent le même répertoire, c'est vraiment du gachis, j'imagine que c'est de là qu'est venu l'idée de centraliser ça dans un démon. Ensuite, le démon choisit entre poller et demander au noyau de le notifier, et les programmes clients n'ont pas à s'en soucier.
En plus, à ce que j'ai vu en survolant la page de man, les fonctions de notifications du noyau sont assez pointues à manipuler (signaux dans tous les sens), ce qui rend compliqué leur intégration dans des programmes qui sont par ailleurs des gros bouzins. Ça plaide aussi pour laisser ça dans un process dédié, qui peut notifier les autres par des mécanismes plus facile à manier (communication à travers une socket).
Enfin, ce ne sont que des raisons qui me viennent à l'esprit comme ça, je ne sait pas si ce sont les vraies raisons.
ZebX :
Donc, si le noyau peut surveiller les changements à quoi sert gamin ?
Si c'est juste pour avertir konqueror et nautilus d'un changement plus
rapidement que le noyau, c'est limité.
La notification de la part du noyau, c'est quelque chose d'assez récent sous
linux, et pas du tout standard. (Il y a-t-il d'autres unix qui ont ça?) Dans
les cas où le noyau ne le supporte pas, il faut bien se démerder avec du
polling. Si plusieurs programment pollent le même répertoire, c'est vraiment
du gachis, j'imagine que c'est de là qu'est venu l'idée de centraliser ça
dans un démon. Ensuite, le démon choisit entre poller et demander au noyau
de le notifier, et les programmes clients n'ont pas à s'en soucier.
En plus, à ce que j'ai vu en survolant la page de man, les fonctions de
notifications du noyau sont assez pointues à manipuler (signaux dans tous
les sens), ce qui rend compliqué leur intégration dans des programmes qui
sont par ailleurs des gros bouzins. Ça plaide aussi pour laisser ça dans un
process dédié, qui peut notifier les autres par des mécanismes plus facile à
manier (communication à travers une socket).
Enfin, ce ne sont que des raisons qui me viennent à l'esprit comme ça, je
ne sait pas si ce sont les vraies raisons.
Donc, si le noyau peut surveiller les changements à quoi sert gamin ? Si c'est juste pour avertir konqueror et nautilus d'un changement plus rapidement que le noyau, c'est limité.
La notification de la part du noyau, c'est quelque chose d'assez récent sous linux, et pas du tout standard. (Il y a-t-il d'autres unix qui ont ça?) Dans les cas où le noyau ne le supporte pas, il faut bien se démerder avec du polling. Si plusieurs programment pollent le même répertoire, c'est vraiment du gachis, j'imagine que c'est de là qu'est venu l'idée de centraliser ça dans un démon. Ensuite, le démon choisit entre poller et demander au noyau de le notifier, et les programmes clients n'ont pas à s'en soucier.
En plus, à ce que j'ai vu en survolant la page de man, les fonctions de notifications du noyau sont assez pointues à manipuler (signaux dans tous les sens), ce qui rend compliqué leur intégration dans des programmes qui sont par ailleurs des gros bouzins. Ça plaide aussi pour laisser ça dans un process dédié, qui peut notifier les autres par des mécanismes plus facile à manier (communication à travers une socket).
Enfin, ce ne sont que des raisons qui me viennent à l'esprit comme ça, je ne sait pas si ce sont les vraies raisons.
l'indien
On Tue, 20 Sep 2005 14:41:38 +0000, Luc Habert wrote:
ZebX :
Donc, si le noyau peut surveiller les changements à quoi sert gamin ? Si c'est juste pour avertir konqueror et nautilus d'un changement plus rapidement que le noyau, c'est limité.
La notification de la part du noyau, c'est quelque chose d'assez récent sous linux, et pas du tout standard. (Il y a-t-il d'autres unix qui ont ça?) Dans les cas où le noyau ne le supporte pas, il faut bien se démerder avec du polling. Si plusieurs programment pollent le même répertoire, c'est vraiment du gachis, j'imagine que c'est de là qu'est venu l'idée de centraliser ça dans un démon. Ensuite, le démon choisit entre poller et demander au noyau de le notifier, et les programmes clients n'ont pas à s'en soucier.
En plus, à ce que j'ai vu en survolant la page de man, les fonctions de notifications du noyau sont assez pointues à manipuler (signaux dans tous les sens), ce qui rend compliqué leur intégration dans des programmes qui sont par ailleurs des gros bouzins.
Je n'ai pas regardé les dernières versions, mais à priori les notifications sont fait par des messages, pas par des signaux. C'est la même approche qui est utilisée dans la couche réseau et je ne pense pas qu'ils aient envie de revenir aux signaux.
Ça plaide aussi pour laisser ça dans un process dédié, qui peut notifier les autres par des mécanismes plus facile à manier (communication à travers une socket).
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon alors qu'il aurait fallu n messages si chaque appli le faisait par elle-même. Ca évite donc de surcharger le noyau et confie le problème du dispatch des messages à un démon, ce qui économise le précieux temps machine utilisé par le noyau.
[...]
On Tue, 20 Sep 2005 14:41:38 +0000, Luc Habert wrote:
ZebX :
Donc, si le noyau peut surveiller les changements à quoi sert gamin ?
Si c'est juste pour avertir konqueror et nautilus d'un changement plus
rapidement que le noyau, c'est limité.
La notification de la part du noyau, c'est quelque chose d'assez récent sous
linux, et pas du tout standard. (Il y a-t-il d'autres unix qui ont ça?) Dans
les cas où le noyau ne le supporte pas, il faut bien se démerder avec du
polling. Si plusieurs programment pollent le même répertoire, c'est vraiment
du gachis, j'imagine que c'est de là qu'est venu l'idée de centraliser ça
dans un démon. Ensuite, le démon choisit entre poller et demander au noyau
de le notifier, et les programmes clients n'ont pas à s'en soucier.
En plus, à ce que j'ai vu en survolant la page de man, les fonctions de
notifications du noyau sont assez pointues à manipuler (signaux dans tous
les sens), ce qui rend compliqué leur intégration dans des programmes qui
sont par ailleurs des gros bouzins.
Je n'ai pas regardé les dernières versions, mais à priori les
notifications sont fait par des messages, pas par des signaux.
C'est la même approche qui est utilisée dans la couche réseau et je ne
pense pas qu'ils aient envie de revenir aux signaux.
Ça plaide aussi pour laisser ça dans un
process dédié, qui peut notifier les autres par des mécanismes plus facile à
manier (communication à travers une socket).
C'est surtout que ça limite la communication avec le noyau: si n process
veulent surveiller un fichier ou un répertoire, il suffit d'un message du
noyau vers le mode user avec un démon alors qu'il aurait fallu n messages
si chaque appli le faisait par elle-même. Ca évite donc de surcharger le
noyau et confie le problème du dispatch des messages à un démon, ce qui
économise le précieux temps machine utilisé par le noyau.
On Tue, 20 Sep 2005 14:41:38 +0000, Luc Habert wrote:
ZebX :
Donc, si le noyau peut surveiller les changements à quoi sert gamin ? Si c'est juste pour avertir konqueror et nautilus d'un changement plus rapidement que le noyau, c'est limité.
La notification de la part du noyau, c'est quelque chose d'assez récent sous linux, et pas du tout standard. (Il y a-t-il d'autres unix qui ont ça?) Dans les cas où le noyau ne le supporte pas, il faut bien se démerder avec du polling. Si plusieurs programment pollent le même répertoire, c'est vraiment du gachis, j'imagine que c'est de là qu'est venu l'idée de centraliser ça dans un démon. Ensuite, le démon choisit entre poller et demander au noyau de le notifier, et les programmes clients n'ont pas à s'en soucier.
En plus, à ce que j'ai vu en survolant la page de man, les fonctions de notifications du noyau sont assez pointues à manipuler (signaux dans tous les sens), ce qui rend compliqué leur intégration dans des programmes qui sont par ailleurs des gros bouzins.
Je n'ai pas regardé les dernières versions, mais à priori les notifications sont fait par des messages, pas par des signaux. C'est la même approche qui est utilisée dans la couche réseau et je ne pense pas qu'ils aient envie de revenir aux signaux.
Ça plaide aussi pour laisser ça dans un process dédié, qui peut notifier les autres par des mécanismes plus facile à manier (communication à travers une socket).
C'est surtout que ça limite la communication avec le noyau: si n process veulent surveiller un fichier ou un répertoire, il suffit d'un message du noyau vers le mode user avec un démon alors qu'il aurait fallu n messages si chaque appli le faisait par elle-même. Ca évite donc de surcharger le noyau et confie le problème du dispatch des messages à un démon, ce qui économise le précieux temps machine utilisé par le noyau.
