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).
Une socket Unix, ça n'est pas accessible pas un simple cat et ça ne
supporte pas le lseek (ou alors je me trompe?).
Merci.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
nous semblons être entouré d'un quarteront de dénigreurs, qui non
seulement n'apportent pas de réponses, mais en plus sèment le doute dans
l'esprit des demandeur... Restez modeste ça fait du bien.
-+- Joe in: Guide du Neuneu d'Usenet - Neuneugaulle, le recours -+-
Mais encore, faut il qu'un quelconque programme soit capable d'accéder à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué, mais je souhaite que ces fichiers virtuels soient accessibles comme n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- RECHERCHE DES INGENIEURS DANS Linformatique IMPORTANT !! Envoyez moi vos cV -+- in Guide du Neuneu sur Usenet : Linformatique pour les nuls -+-
On 28 Oct 2003, Pascal Bourguignon wrote:
[...]
Mais encore, faut il qu'un quelconque programme soit capable d'accéder
à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué,
mais je souhaite que ces fichiers virtuels soient accessibles comme
n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est
de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
RECHERCHE DES INGENIEURS DANS Linformatique IMPORTANT !!
Envoyez moi vos cV
-+- in Guide du Neuneu sur Usenet : Linformatique pour les nuls -+-
Mais encore, faut il qu'un quelconque programme soit capable d'accéder à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué, mais je souhaite que ces fichiers virtuels soient accessibles comme n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- RECHERCHE DES INGENIEURS DANS Linformatique IMPORTANT !! Envoyez moi vos cV -+- in Guide du Neuneu sur Usenet : Linformatique pour les nuls -+-
Thomas Nemeth
Le mar 28 oct 2003 à 18:14, Erwann ABALEA a tapoté :
Salut Erwann.
| J'ai bien l'impression qu'il n'y a pas de solution simple....
Non :) Rien que l'énoncé en soi n'est pas simple. Ceci dit, il te reste tout de même 2 autres solutions !
La première, la plus tordue évidemment, est de faire un translator hurd ;) Mais c'est fortement non portable :)
La seconde serait de faire un ajout à userfs : http://www.goop.org/~jeremy/userfs/ même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Thomas -- BOFH excuse #345: Having to manually track the satellite.
Le mar 28 oct 2003 à 18:14, Erwann ABALEA a tapoté :
Salut Erwann.
| J'ai bien l'impression qu'il n'y a pas de solution simple....
Non :) Rien que l'énoncé en soi n'est pas simple. Ceci dit, il
te reste tout de même 2 autres solutions !
La première, la plus tordue évidemment, est de faire un
translator hurd ;) Mais c'est fortement non portable :)
La seconde serait de faire un ajout à userfs :
http://www.goop.org/~jeremy/userfs/
même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Thomas
--
BOFH excuse #345:
Having to manually track the satellite.
Le mar 28 oct 2003 à 18:14, Erwann ABALEA a tapoté :
Salut Erwann.
| J'ai bien l'impression qu'il n'y a pas de solution simple....
Non :) Rien que l'énoncé en soi n'est pas simple. Ceci dit, il te reste tout de même 2 autres solutions !
La première, la plus tordue évidemment, est de faire un translator hurd ;) Mais c'est fortement non portable :)
La seconde serait de faire un ajout à userfs : http://www.goop.org/~jeremy/userfs/ même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Thomas -- BOFH excuse #345: Having to manually track the satellite.
Stephane Chazelas
2003/10/28, 18:14(+01), Erwann ABALEA:
[...]
Mais encore, faut il qu'un quelconque programme soit capable d'accéder à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué, mais je souhaite que ces fichiers virtuels soient accessibles comme n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
Je la trouve plutot simple, la solution du LD_PRELOAD, une 20aine de lignes de C à vue de nez (de quoi maintenir une trace des fd/seek-position... et la redirection des fonctions). Pas de programme à faire tourner, le code est partagé (dans un .so). Tu peux utiliser des mmap pour accéder aux fichiers à merger.
Pas trop d'impact sur les performances. C'est pas mal portable (Linux, Solaris, HPUX au moins). Pas besoin d'etre root tant que tu n'utilises pas de programmes setuid... C'est quoi qui te retiens ?
Mais encore, faut il qu'un quelconque programme soit capable d'accéder
à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué,
mais je souhaite que ces fichiers virtuels soient accessibles comme
n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est
de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
Je la trouve plutot simple, la solution du LD_PRELOAD, une
20aine de lignes de C à vue de nez (de quoi maintenir une trace
des fd/seek-position... et la redirection des fonctions). Pas de
programme à faire tourner, le code est partagé (dans un .so). Tu
peux utiliser des mmap pour accéder aux fichiers à merger.
Pas trop d'impact sur les performances. C'est pas mal portable
(Linux, Solaris, HPUX au moins). Pas besoin d'etre root tant que
tu n'utilises pas de programmes setuid... C'est quoi qui te
retiens ?
Mais encore, faut il qu'un quelconque programme soit capable d'accéder à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué, mais je souhaite que ces fichiers virtuels soient accessibles comme n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
Je la trouve plutot simple, la solution du LD_PRELOAD, une 20aine de lignes de C à vue de nez (de quoi maintenir une trace des fd/seek-position... et la redirection des fonctions). Pas de programme à faire tourner, le code est partagé (dans un .so). Tu peux utiliser des mmap pour accéder aux fichiers à merger.
Pas trop d'impact sur les performances. C'est pas mal portable (Linux, Solaris, HPUX au moins). Pas besoin d'etre root tant que tu n'utilises pas de programmes setuid... C'est quoi qui te retiens ?
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, ...).
Après quelques minutes de réflexion, il apparaît que la solution d'un pseudo serveur NFS est tout à fait portable, tant qu'on n'écrit que le serveur. Il faut juste que je n'ai pas de vrai serveur NFS sur la même machine.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- A big enough hammer fixes anything.
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Après quelques minutes de réflexion, il apparaît que la solution d'un
pseudo serveur NFS est tout à fait portable, tant qu'on n'écrit que le
serveur. Il faut juste que je n'ai pas de vrai serveur NFS sur la même
machine.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
A big enough hammer fixes anything.
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, ...).
Après quelques minutes de réflexion, il apparaît que la solution d'un pseudo serveur NFS est tout à fait portable, tant qu'on n'écrit que le serveur. Il faut juste que je n'ai pas de vrai serveur NFS sur la même machine.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- A big enough hammer fixes anything.
Pascal Bourguignon
Erwann ABALEA writes:
On 28 Oct 2003, Pascal Bourguignon wrote:
[...]
Mais encore, faut il qu'un quelconque programme soit capable d'accéder à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué, mais je souhaite que ces fichiers virtuels soient accessibles comme n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
En lecture seule et à coup de grep, awk etc ?
La plupart des commandes acceptent plusieurs fichiers en argument et les traitent l'un après l'autre quasiment comme s'ils étaient concaténés:
cat fic* | grep pattern
donne le même résultat que:
grep -h pattern fic*
awk, sed, font de même...
Sinon, s'il ne s'agit pas de trop gros fichiers (par rapport à la place disponible), il reste la possibilité de les concaténer effectivement, ce qui pose d'autant moins de problème qu'ils sont en lecture seule.
Mais encore, faut il qu'un quelconque programme soit capable d'accéder
à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué,
mais je souhaite que ces fichiers virtuels soient accessibles comme
n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est
de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
En lecture seule et à coup de grep, awk etc ?
La plupart des commandes acceptent plusieurs fichiers en argument et
les traitent l'un après l'autre quasiment comme s'ils étaient
concaténés:
cat fic* | grep pattern
donne le même résultat que:
grep -h pattern fic*
awk, sed, font de même...
Sinon, s'il ne s'agit pas de trop gros fichiers (par rapport à la
place disponible), il reste la possibilité de les concaténer
effectivement, ce qui pose d'autant moins de problème qu'ils sont en
lecture seule.
Mais encore, faut il qu'un quelconque programme soit capable d'accéder à ces fichiers virtuels?
Oui. Dans mon post initial, je ne sais pas si c'était clairement indiqué, mais je souhaite que ces fichiers virtuels soient accessibles comme n'importe quel autre fichier (en lecture seule, ça me suffit). Le but est de traiter les fichiers virtuels à coup de grep, awk, et autres...
J'ai bien l'impression qu'il n'y a pas de solution simple....
En lecture seule et à coup de grep, awk etc ?
La plupart des commandes acceptent plusieurs fichiers en argument et les traitent l'un après l'autre quasiment comme s'ils étaient concaténés:
cat fic* | grep pattern
donne le même résultat que:
grep -h pattern fic*
awk, sed, font de même...
Sinon, s'il ne s'agit pas de trop gros fichiers (par rapport à la place disponible), il reste la possibilité de les concaténer effectivement, ce qui pose d'autant moins de problème qu'ils sont en lecture seule.
Je la trouve plutot simple, la solution du LD_PRELOAD, une 20aine de lignes de C à vue de nez (de quoi maintenir une trace des fd/seek-position... et la redirection des fonctions). Pas de programme à faire tourner, le code est partagé (dans un .so). Tu peux utiliser des mmap pour accéder aux fichiers à merger.
A la réflexion, tu as raison. Je dois juste ranger mes fichiers virtuels dans un répertoire particulier, qui servira de 'trigger' pour la bibliothèque. J'ai quelques fonctions à intercepter pour faire mon travail (open, read, lseek, close, *stat, potentiellement readdir), et d'autres pour simplement renvoyer une erreur (write, unlink, ...).
Pas trop d'impact sur les performances. C'est pas mal portable (Linux, Solaris, HPUX au moins). Pas besoin d'etre root tant que tu n'utilises pas de programmes setuid... C'est quoi qui te retiens ?
J'avais mal évalué cette solution. Dans mon esprit, j'imaginais quelque chose de centralisé, soit un daemon, soit un driver, soit... J'associais aussi l'utilisation du LD_PRELOAD au mécanisme des TSR sous DOS, qui est une rustine pour OS déficient, et ça ne me paraissait pas très 'propre' comme approche, je préférais un mécanisme dédié à ce que je souhaitais faire.
Finalement, ta solution gagne pas mal de points: elle semble portable (au moins POSIX), elle est complètement userland, elle ne nécessite pas d'être root, elle a l'air simple. Ca semble impec.
Bon, ben j'ai plus qu'à coder maintenant... ;)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Normalement un enfant a le droit de monter à l'avant de l'automobile à partir de 10 ans, âge à partir duquel il compte pour une personne. Avant il ne compte que pour une demi-personne. -+- MCG in : Guide du Neuneu d'Usenet - En voiture Simone -+-
On Tue, 28 Oct 2003, Stephane Chazelas wrote:
[...]
Je la trouve plutot simple, la solution du LD_PRELOAD, une
20aine de lignes de C à vue de nez (de quoi maintenir une trace
des fd/seek-position... et la redirection des fonctions). Pas de
programme à faire tourner, le code est partagé (dans un .so). Tu
peux utiliser des mmap pour accéder aux fichiers à merger.
A la réflexion, tu as raison. Je dois juste ranger mes fichiers virtuels
dans un répertoire particulier, qui servira de 'trigger' pour la
bibliothèque. J'ai quelques fonctions à intercepter pour faire mon travail
(open, read, lseek, close, *stat, potentiellement readdir), et d'autres
pour simplement renvoyer une erreur (write, unlink, ...).
Pas trop d'impact sur les performances. C'est pas mal portable
(Linux, Solaris, HPUX au moins). Pas besoin d'etre root tant que
tu n'utilises pas de programmes setuid... C'est quoi qui te
retiens ?
J'avais mal évalué cette solution. Dans mon esprit, j'imaginais quelque
chose de centralisé, soit un daemon, soit un driver, soit...
J'associais aussi l'utilisation du LD_PRELOAD au mécanisme des TSR sous
DOS, qui est une rustine pour OS déficient, et ça ne me paraissait pas
très 'propre' comme approche, je préférais un mécanisme dédié à ce que je
souhaitais faire.
Finalement, ta solution gagne pas mal de points: elle semble portable (au
moins POSIX), elle est complètement userland, elle ne nécessite pas d'être
root, elle a l'air simple. Ca semble impec.
Bon, ben j'ai plus qu'à coder maintenant... ;)
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Normalement un enfant a le droit de monter à l'avant de l'automobile à
partir de 10 ans, âge à partir duquel il compte pour une personne. Avant
il ne compte que pour une demi-personne.
-+- MCG in : Guide du Neuneu d'Usenet - En voiture Simone -+-
Je la trouve plutot simple, la solution du LD_PRELOAD, une 20aine de lignes de C à vue de nez (de quoi maintenir une trace des fd/seek-position... et la redirection des fonctions). Pas de programme à faire tourner, le code est partagé (dans un .so). Tu peux utiliser des mmap pour accéder aux fichiers à merger.
A la réflexion, tu as raison. Je dois juste ranger mes fichiers virtuels dans un répertoire particulier, qui servira de 'trigger' pour la bibliothèque. J'ai quelques fonctions à intercepter pour faire mon travail (open, read, lseek, close, *stat, potentiellement readdir), et d'autres pour simplement renvoyer une erreur (write, unlink, ...).
Pas trop d'impact sur les performances. C'est pas mal portable (Linux, Solaris, HPUX au moins). Pas besoin d'etre root tant que tu n'utilises pas de programmes setuid... C'est quoi qui te retiens ?
J'avais mal évalué cette solution. Dans mon esprit, j'imaginais quelque chose de centralisé, soit un daemon, soit un driver, soit... J'associais aussi l'utilisation du LD_PRELOAD au mécanisme des TSR sous DOS, qui est une rustine pour OS déficient, et ça ne me paraissait pas très 'propre' comme approche, je préférais un mécanisme dédié à ce que je souhaitais faire.
Finalement, ta solution gagne pas mal de points: elle semble portable (au moins POSIX), elle est complètement userland, elle ne nécessite pas d'être root, elle a l'air simple. Ca semble impec.
Bon, ben j'ai plus qu'à coder maintenant... ;)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Normalement un enfant a le droit de monter à l'avant de l'automobile à partir de 10 ans, âge à partir duquel il compte pour une personne. Avant il ne compte que pour une demi-personne. -+- MCG in : Guide du Neuneu d'Usenet - En voiture Simone -+-
Erwann ABALEA
Salut Thomas,
On 28 Oct 2003, Thomas Nemeth wrote:
Le mar 28 oct 2003 à 18:14, Erwann ABALEA a tapoté :
| J'ai bien l'impression qu'il n'y a pas de solution simple....
Non :) Rien que l'énoncé en soi n'est pas simple. Ceci dit, il te reste tout de même 2 autres solutions !
Je n'ai pas envie d'en dire trop, je ne sais pas si je vais trouver le temps d'écrire ce machin, mais d'après les réponses que j'ai eu, je pense que j'ai réussi à faire comprendre mon besoin. ;)
La première, la plus tordue évidemment, est de faire un translator hurd ;) Mais c'est fortement non portable :)
Ah oui mais non. :) J'ai déjà 2 cibles en tête: Linux et Solaris.
La seconde serait de faire un ajout à userfs : http://www.goop.org/~jeremy/userfs/ même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Ah? Ben un bookmark en plus.
Merci.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Tu as une vision obsolète du Net. Les groupes sont hébergés chez les FAI maintenant. Il FAUT que leur gestion change. -+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
Salut Thomas,
On 28 Oct 2003, Thomas Nemeth wrote:
Le mar 28 oct 2003 à 18:14, Erwann ABALEA a tapoté :
| J'ai bien l'impression qu'il n'y a pas de solution simple....
Non :) Rien que l'énoncé en soi n'est pas simple. Ceci dit, il
te reste tout de même 2 autres solutions !
Je n'ai pas envie d'en dire trop, je ne sais pas si je vais trouver le
temps d'écrire ce machin, mais d'après les réponses que j'ai eu, je pense
que j'ai réussi à faire comprendre mon besoin. ;)
La première, la plus tordue évidemment, est de faire un
translator hurd ;) Mais c'est fortement non portable :)
Ah oui mais non. :)
J'ai déjà 2 cibles en tête: Linux et Solaris.
La seconde serait de faire un ajout à userfs :
http://www.goop.org/~jeremy/userfs/
même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Ah? Ben un bookmark en plus.
Merci.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Tu as une vision obsolète du Net. Les groupes sont hébergés chez les
FAI maintenant. Il FAUT que leur gestion change.
-+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
Le mar 28 oct 2003 à 18:14, Erwann ABALEA a tapoté :
| J'ai bien l'impression qu'il n'y a pas de solution simple....
Non :) Rien que l'énoncé en soi n'est pas simple. Ceci dit, il te reste tout de même 2 autres solutions !
Je n'ai pas envie d'en dire trop, je ne sais pas si je vais trouver le temps d'écrire ce machin, mais d'après les réponses que j'ai eu, je pense que j'ai réussi à faire comprendre mon besoin. ;)
La première, la plus tordue évidemment, est de faire un translator hurd ;) Mais c'est fortement non portable :)
Ah oui mais non. :) J'ai déjà 2 cibles en tête: Linux et Solaris.
La seconde serait de faire un ajout à userfs : http://www.goop.org/~jeremy/userfs/ même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Ah? Ben un bookmark en plus.
Merci.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Tu as une vision obsolète du Net. Les groupes sont hébergés chez les FAI maintenant. Il FAUT que leur gestion change. -+- Rocou in GNU : l'avenir appartient à ceux qui neuneutent tôt -+-
Vincent Bernat
OoO En cette matinée ensoleillée du mardi 28 octobre 2003, vers 09:30, Thomas Nemeth disait:
La seconde serait de faire un ajout à userfs : http://www.goop.org/~jeremy/userfs/ même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Je n'ai pas trop le temps de chercher, mais il existe des projets actifs qui font la même chose que userfs. Il serait dommage d'utiliser un projet mort (pour mauvaise conception il me semble). Un peu de Google... -- I WILL NOT FAKE SEIZURES I WILL NOT FAKE SEIZURES I WILL NOT FAKE SEIZURES -+- Bart Simpson on chalkboard in episode 8F23
OoO En cette matinée ensoleillée du mardi 28 octobre 2003, vers 09:30,
Thomas Nemeth <thomas@exether.vipere.noire> disait:
La seconde serait de faire un ajout à userfs :
http://www.goop.org/~jeremy/userfs/
même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Je n'ai pas trop le temps de chercher, mais il existe des projets
actifs qui font la même chose que userfs. Il serait dommage d'utiliser
un projet mort (pour mauvaise conception il me semble). Un peu de
Google...
--
I WILL NOT FAKE SEIZURES
I WILL NOT FAKE SEIZURES
I WILL NOT FAKE SEIZURES
-+- Bart Simpson on chalkboard in episode 8F23
OoO En cette matinée ensoleillée du mardi 28 octobre 2003, vers 09:30, Thomas Nemeth disait:
La seconde serait de faire un ajout à userfs : http://www.goop.org/~jeremy/userfs/ même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
Je n'ai pas trop le temps de chercher, mais il existe des projets actifs qui font la même chose que userfs. Il serait dommage d'utiliser un projet mort (pour mauvaise conception il me semble). Un peu de Google... -- I WILL NOT FAKE SEIZURES I WILL NOT FAKE SEIZURES I WILL NOT FAKE SEIZURES -+- Bart Simpson on chalkboard in episode 8F23
Thomas Nemeth
Le mar 28 oct 2003 à 22:08, Vincent Bernat a tapoté : | OoO En cette matinée ensoleillée du mardi 28 octobre 2003, vers 09:30, | Thomas Nemeth disait: | | > La seconde serait de faire un ajout à userfs : | > http://www.goop.org/~jeremy/userfs/ | > même s'il est abandonné, tu dois pouvoir en tirer quelquechose. | | Je n'ai pas trop le temps de chercher, mais il existe des projets | actifs qui font la même chose que userfs. Il serait dommage d'utiliser | un projet mort (pour mauvaise conception il me semble). Un peu de | Google...
Effectivement. J'ai cité userfs car je l'avais en mémoire et dans mes bookmarks.
Thomas -- prom_printf("Detected PenguinPages, getting out of here.n"); 2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c
Le mar 28 oct 2003 à 22:08, Vincent Bernat a tapoté :
| OoO En cette matinée ensoleillée du mardi 28 octobre 2003, vers 09:30,
| Thomas Nemeth <thomas@exether.vipere.noire> disait:
|
| > La seconde serait de faire un ajout à userfs :
| > http://www.goop.org/~jeremy/userfs/
| > même s'il est abandonné, tu dois pouvoir en tirer quelquechose.
|
| Je n'ai pas trop le temps de chercher, mais il existe des projets
| actifs qui font la même chose que userfs. Il serait dommage d'utiliser
| un projet mort (pour mauvaise conception il me semble). Un peu de
| Google...
Effectivement. J'ai cité userfs car je l'avais en mémoire et dans
mes bookmarks.
Thomas
--
prom_printf("Detected PenguinPages, getting out of here.n");
2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c
Le mar 28 oct 2003 à 22:08, Vincent Bernat a tapoté : | OoO En cette matinée ensoleillée du mardi 28 octobre 2003, vers 09:30, | Thomas Nemeth disait: | | > La seconde serait de faire un ajout à userfs : | > http://www.goop.org/~jeremy/userfs/ | > même s'il est abandonné, tu dois pouvoir en tirer quelquechose. | | Je n'ai pas trop le temps de chercher, mais il existe des projets | actifs qui font la même chose que userfs. Il serait dommage d'utiliser | un projet mort (pour mauvaise conception il me semble). Un peu de | Google...
Effectivement. J'ai cité userfs car je l'avais en mémoire et dans mes bookmarks.
Thomas -- prom_printf("Detected PenguinPages, getting out of here.n"); 2.0.38 /usr/src/linux/arch/sparc/mm/srmmu.c
Jean-Marc Bourguet
Erwann ABALEA writes:
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Après quelques minutes de réflexion, il apparaît que la solution d'un pseudo serveur NFS est tout à fait portable, tant qu'on n'écrit que le serveur. Il faut juste que je n'ai pas de vrai serveur NFS sur la même machine.
Si j'ai bonne memoire, c'est possible de specifier le port (et donc tu peux avoir plusieurs serveurs NFS sur la meme machine servant des ports differents).
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Erwann ABALEA <erwann@abalea.com> writes:
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Après quelques minutes de réflexion, il apparaît que la solution d'un
pseudo serveur NFS est tout à fait portable, tant qu'on n'écrit que le
serveur. Il faut juste que je n'ai pas de vrai serveur NFS sur la même
machine.
Si j'ai bonne memoire, c'est possible de specifier le port (et donc tu
peux avoir plusieurs serveurs NFS sur la meme machine servant des
ports differents).
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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, ...).
Après quelques minutes de réflexion, il apparaît que la solution d'un pseudo serveur NFS est tout à fait portable, tant qu'on n'écrit que le serveur. Il faut juste que je n'ai pas de vrai serveur NFS sur la même machine.
Si j'ai bonne memoire, c'est possible de specifier le port (et donc tu peux avoir plusieurs serveurs NFS sur la meme machine servant des ports differents).
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
