Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
Un fichier simple, ça ne marche pas, le contenu est 'réel', et j'ai besoin
que ce contenu soit dépendant du bon vouloir d'une application, sans pour
autant devoir réécrire le fichier. De plus, je ne veux pas que ça occupe
beaucoup de place sur le disque, quelle que soit la quantité de données
accessible.
Un tube nommé, il ne peut y avoir qu'un seul lecteur à la fois, et le
lseek est limité au buffer interne du noyau (4k sous Linux).
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
Un fichier simple, ça ne marche pas, le contenu est 'réel', et j'ai besoin
que ce contenu soit dépendant du bon vouloir d'une application, sans pour
autant devoir réécrire le fichier. De plus, je ne veux pas que ça occupe
beaucoup de place sur le disque, quelle que soit la quantité de données
accessible.
Un tube nommé, il ne peut y avoir qu'un seul lecteur à la fois, et le
lseek est limité au buffer interne du noyau (4k sous Linux).
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
Un fichier simple, ça ne marche pas, le contenu est 'réel', et j'ai besoin
que ce contenu soit dépendant du bon vouloir d'une application, sans pour
autant devoir réécrire le fichier. De plus, je ne veux pas que ça occupe
beaucoup de place sur le disque, quelle que soit la quantité de données
accessible.
Un tube nommé, il ne peut y avoir qu'un seul lecteur à la fois, et le
lseek est limité au buffer interne du noyau (4k sous Linux).
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
Erwann ABALEA écrit:Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
Les fichiers d'un système de fichier sans disque.
Un fichier simple, ça ne marche pas, le contenu est 'réel', et j'ai besoin
que ce contenu soit dépendant du bon vouloir d'une application, sans pour
autant devoir réécrire le fichier. De plus, je ne veux pas que ça occupe
beaucoup de place sur le disque, quelle que soit la quantité de données
accessible.
Faut bien mettre les données quelque part. Dans un système de fichier
mémoire, par exemple.
Un tube nommé, il ne peut y avoir qu'un seul lecteur à la fois, et le
lseek est limité au buffer interne du noyau (4k sous Linux).
Ce n'est pas garanti que lseek fonctionne sur les tubes.
Erwann ABALEA <erwann@abalea.com> écrit:
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
Les fichiers d'un système de fichier sans disque.
Un fichier simple, ça ne marche pas, le contenu est 'réel', et j'ai besoin
que ce contenu soit dépendant du bon vouloir d'une application, sans pour
autant devoir réécrire le fichier. De plus, je ne veux pas que ça occupe
beaucoup de place sur le disque, quelle que soit la quantité de données
accessible.
Faut bien mettre les données quelque part. Dans un système de fichier
mémoire, par exemple.
Un tube nommé, il ne peut y avoir qu'un seul lecteur à la fois, et le
lseek est limité au buffer interne du noyau (4k sous Linux).
Ce n'est pas garanti que lseek fonctionne sur les tubes.
Erwann ABALEA écrit:Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
Les fichiers d'un système de fichier sans disque.
Un fichier simple, ça ne marche pas, le contenu est 'réel', et j'ai besoin
que ce contenu soit dépendant du bon vouloir d'une application, sans pour
autant devoir réécrire le fichier. De plus, je ne veux pas que ça occupe
beaucoup de place sur le disque, quelle que soit la quantité de données
accessible.
Faut bien mettre les données quelque part. Dans un système de fichier
mémoire, par exemple.
Un tube nommé, il ne peut y avoir qu'un seul lecteur à la fois, et le
lseek est limité au buffer interne du noyau (4k sous Linux).
Ce n'est pas garanti que lseek fonctionne sur les tubes.
2003/10/27, 18:26(+01), Erwann ABALEA:Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
C'est pour quoi faire ?
Peut-etre que tu peux mettre un wrapper à base de LD_PRELOAD
autour des applications qui accèdent aux fichiers en redirigeant
les open, close, read, lseek.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
2003/10/27, 18:26(+01), Erwann ABALEA:
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
C'est pour quoi faire ?
Peut-etre que tu peux mettre un wrapper à base de LD_PRELOAD
autour des applications qui accèdent aux fichiers en redirigeant
les open, close, read, lseek.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
2003/10/27, 18:26(+01), Erwann ABALEA:Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
C'est pour quoi faire ?
Peut-etre que tu peux mettre un wrapper à base de LD_PRELOAD
autour des applications qui accèdent aux fichiers en redirigeant
les open, close, read, lseek.
ne vous inquiétez pas, ce n'est pas possible via Usenet :)
-+-LW in Guide du Neuneu Usenet - Après les mouches, à qui le tour ? -+-
Donc à part le character device et le système de fichier virtuel, il
n'existe rien qui satisfasse aux conditions? Ces 2 solutions nécessitent
du code qui ne tourne pas en userland, et qui n'est certainement pas
portable. Génant.
Donc à part le character device et le système de fichier virtuel, il
n'existe rien qui satisfasse aux conditions? Ces 2 solutions nécessitent
du code qui ne tourne pas en userland, et qui n'est certainement pas
portable. Génant.
Donc à part le character device et le système de fichier virtuel, il
n'existe rien qui satisfasse aux conditions? Ces 2 solutions nécessitent
du code qui ne tourne pas en userland, et qui n'est certainement pas
portable. Génant.
On Mon, 27 Oct 2003, Stephane Chazelas wrote:2003/10/27, 18:26(+01), Erwann ABALEA:Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
C'est pour quoi faire ?
Très bonne question. Le but est de 'réunir' plusieurs fichiers en un seul,
mais de façon virtuelle, en offrant un point d'entrée unique. On peut
imaginer la situation suivante:
- fichier /a/file1.dat
- fichier /b/file2.dat
- pseudo-fichier /c/merge.dat
Et toute lecture de /c/merge.dat renverra du contenu dépendant de
/a/file1.dat et /b/file2.dat (ce qui se trouve derrière le 'dépendant' n'a
pas besoin d'être expliqué). Je ne veux pas que merge.dat prenne de la
place disque (autrement que par sa représentation), puisque les données se
trouvent déjà ailleurs.
Je ne sais pas si mon exemple est suffisamment parlant.Peut-etre que tu peux mettre un wrapper à base de LD_PRELOAD
autour des applications qui accèdent aux fichiers en redirigeant
les open, close, read, lseek.
Hmmmm. Possible, mais le système de fichier virtuel me parait plus
élégant, et le character device moins 'bricolage'. ;)
Je vais quand même y réfléchir. Ca me fait 3 mécanismes potentiels... Mais
rien de vraiment portable, et en tout cas rien qui tourne simplement en
userland...
On Mon, 27 Oct 2003, Stephane Chazelas wrote:
2003/10/27, 18:26(+01), Erwann ABALEA:
Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
C'est pour quoi faire ?
Très bonne question. Le but est de 'réunir' plusieurs fichiers en un seul,
mais de façon virtuelle, en offrant un point d'entrée unique. On peut
imaginer la situation suivante:
- fichier /a/file1.dat
- fichier /b/file2.dat
- pseudo-fichier /c/merge.dat
Et toute lecture de /c/merge.dat renverra du contenu dépendant de
/a/file1.dat et /b/file2.dat (ce qui se trouve derrière le 'dépendant' n'a
pas besoin d'être expliqué). Je ne veux pas que merge.dat prenne de la
place disque (autrement que par sa représentation), puisque les données se
trouvent déjà ailleurs.
Je ne sais pas si mon exemple est suffisamment parlant.
Peut-etre que tu peux mettre un wrapper à base de LD_PRELOAD
autour des applications qui accèdent aux fichiers en redirigeant
les open, close, read, lseek.
Hmmmm. Possible, mais le système de fichier virtuel me parait plus
élégant, et le character device moins 'bricolage'. ;)
Je vais quand même y réfléchir. Ca me fait 3 mécanismes potentiels... Mais
rien de vraiment portable, et en tout cas rien qui tourne simplement en
userland...
On Mon, 27 Oct 2003, Stephane Chazelas wrote:2003/10/27, 18:26(+01), Erwann ABALEA:Est-ce qu'il existe un 'objet' (fichier, socket, device, ...) Unix qui:
- puisse être accédé en lecture par plusieurs process simultanément
- supporte les appels type lseek (donc à accès aléatoire)
- dont le contenu puisse être 'virtuel' (i.e. un peu comme un tube
nommé, qui ne consomme quasimment rien sur disque)
- puisse être accédé comme un simple fichier, par un cat, more, grep, ...
(donc pas comme une socket)
Réunissant toutes ces conditions, je ne vois que les devices en mode
caractère, mais il est possible que j'oublie des trucs...
[...]
C'est pour quoi faire ?
Très bonne question. Le but est de 'réunir' plusieurs fichiers en un seul,
mais de façon virtuelle, en offrant un point d'entrée unique. On peut
imaginer la situation suivante:
- fichier /a/file1.dat
- fichier /b/file2.dat
- pseudo-fichier /c/merge.dat
Et toute lecture de /c/merge.dat renverra du contenu dépendant de
/a/file1.dat et /b/file2.dat (ce qui se trouve derrière le 'dépendant' n'a
pas besoin d'être expliqué). Je ne veux pas que merge.dat prenne de la
place disque (autrement que par sa représentation), puisque les données se
trouvent déjà ailleurs.
Je ne sais pas si mon exemple est suffisamment parlant.Peut-etre que tu peux mettre un wrapper à base de LD_PRELOAD
autour des applications qui accèdent aux fichiers en redirigeant
les open, close, read, lseek.
Hmmmm. Possible, mais le système de fichier virtuel me parait plus
élégant, et le character device moins 'bricolage'. ;)
Je vais quand même y réfléchir. Ca me fait 3 mécanismes potentiels... Mais
rien de vraiment portable, et en tout cas rien qui tourne simplement en
userland...
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
Tu as donc un système de fichier complet, portable, et même orienté
reseaux...
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
Tu as donc un système de fichier complet, portable, et même orienté
reseaux...
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
Tu as donc un système de fichier complet, portable, et même orienté
reseaux...
Erwann ABALEA écrit:Donc à part le character device et le système de fichier virtuel, il
n'existe rien qui satisfasse aux conditions? Ces 2 solutions nécessitent
du code qui ne tourne pas en userland, et qui n'est certainement pas
portable. Génant.
Si tu veux pouvoir faire seek() sans avoir de cache, il faut que les
données puissent être recalculées aléatoirement. Si c'est la sortie
d'un programe, ce programme doit pouvoir intercepter l'appel à seek()
ce qui ne peut se faire sans collaboration du système de fichier.
Erwann ABALEA <erwann@abalea.com> écrit:
Donc à part le character device et le système de fichier virtuel, il
n'existe rien qui satisfasse aux conditions? Ces 2 solutions nécessitent
du code qui ne tourne pas en userland, et qui n'est certainement pas
portable. Génant.
Si tu veux pouvoir faire seek() sans avoir de cache, il faut que les
données puissent être recalculées aléatoirement. Si c'est la sortie
d'un programe, ce programme doit pouvoir intercepter l'appel à seek()
ce qui ne peut se faire sans collaboration du système de fichier.
Erwann ABALEA écrit:Donc à part le character device et le système de fichier virtuel, il
n'existe rien qui satisfasse aux conditions? Ces 2 solutions nécessitent
du code qui ne tourne pas en userland, et qui n'est certainement pas
portable. Génant.
Si tu veux pouvoir faire seek() sans avoir de cache, il faut que les
données puissent être recalculées aléatoirement. Si c'est la sortie
d'un programe, ce programme doit pouvoir intercepter l'appel à seek()
ce qui ne peut se faire sans collaboration du système de fichier.
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
On Tue, 28 Oct 2003, no wrote:
[...]- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
Ca n'est pas une troisième solution, c'est la même chose que le système de
fichier virtuel. D'ailleurs ont peut supprimer le 'virtuel', il s'agit
d'un système de fichier tout court. Que les données soient physiquement
ici, ailleurs, ou générées à la volée, peu importe.
Il faut que je regarde comment le usermode NFS fonctionne. C'est déjà
mieux d'avoir ça en userland qu'en noyau, mais là non plus, ça n'est pas
très portable (comprendre: les détails seront forcément différents sous
Solaris, HP/UX, AIX, ...).
J'ai donc toujours 3 solutions, dont une peut être implémentée en
userland, mais aucune de portable. Et aucune d'aussi 'élégante' et simple
qu'un socket, un tube nommé, ou autre machin quasimment natif.
Merci pour vos réponses.
On Tue, 28 Oct 2003, no wrote:
[...]
- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
Ca n'est pas une troisième solution, c'est la même chose que le système de
fichier virtuel. D'ailleurs ont peut supprimer le 'virtuel', il s'agit
d'un système de fichier tout court. Que les données soient physiquement
ici, ailleurs, ou générées à la volée, peu importe.
Il faut que je regarde comment le usermode NFS fonctionne. C'est déjà
mieux d'avoir ça en userland qu'en noyau, mais là non plus, ça n'est pas
très portable (comprendre: les détails seront forcément différents sous
Solaris, HP/UX, AIX, ...).
J'ai donc toujours 3 solutions, dont une peut être implémentée en
userland, mais aucune de portable. Et aucune d'aussi 'élégante' et simple
qu'un socket, un tube nommé, ou autre machin quasimment natif.
Merci pour vos réponses.
On Tue, 28 Oct 2003, no wrote:
[...]- 3éme solution :
C'est de passer par un serveur NFS en « userspace » comme l'ancien
serveur NFS de Linux (`nfs-server', avant que ça ne soit géré par le
kernel).
Tu as d'un coté une interface NFS classique accessible par
n'importe quel client (un simple mount), ensuite tu implementes toi même
les mécanismes internes du serveur et d'accés aux vrais fichiers avec ta
gestion de « merge »...
Ca n'est pas une troisième solution, c'est la même chose que le système de
fichier virtuel. D'ailleurs ont peut supprimer le 'virtuel', il s'agit
d'un système de fichier tout court. Que les données soient physiquement
ici, ailleurs, ou générées à la volée, peu importe.
Il faut que je regarde comment le usermode NFS fonctionne. C'est déjà
mieux d'avoir ça en userland qu'en noyau, mais là non plus, ça n'est pas
très portable (comprendre: les détails seront forcément différents sous
Solaris, HP/UX, AIX, ...).
J'ai donc toujours 3 solutions, dont une peut être implémentée en
userland, mais aucune de portable. Et aucune d'aussi 'élégante' et simple
qu'un socket, un tube nommé, ou autre machin quasimment natif.
Merci pour vos réponses.
