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 -+-
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- ``There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.'' Mark Twain
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais
pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de
libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il
n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de
LD_PRELOAD?
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
``There are basically two types of people.
People who accomplish things, and people who claim to have accomplished
things. The first group is less crowded.''
Mark Twain
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- ``There are basically two types of people. People who accomplish things, and people who claim to have accomplished things. The first group is less crowded.'' Mark Twain
Erwann ABALEA
On 28 Oct 2003, Pascal Bourguignon wrote:
Erwann ABALEA writes:
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 ?
Exact.
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:
Je sais, merci. Mais ça n'est pas envisageable, parce que les fichiers ne doivent pas être bêtement concaténés. Ils doivent être modifiés, réarrangés, secoués, ...
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.
Pas envisageable. Ces fichiers changent très régulièrement, et peuvent atteindre plusieurs centaines de Mo chacun.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- quand j'utilise la roulette avec la souris ps/2 weel mouse cros$oft aprés 2/3 recherches je subis un gel d'écran soyez prudent il y a peut-être des risques d'esplosion du moniteur... -+- FM in GNU : la souris rit, la roulette ruse et tout explose -+-
On 28 Oct 2003, Pascal Bourguignon wrote:
Erwann ABALEA <erwann@abalea.com> writes:
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 ?
Exact.
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:
Je sais, merci. Mais ça n'est pas envisageable, parce que les fichiers ne
doivent pas être bêtement concaténés. Ils doivent être modifiés,
réarrangés, secoués, ...
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.
Pas envisageable. Ces fichiers changent très régulièrement, et peuvent
atteindre plusieurs centaines de Mo chacun.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
quand j'utilise la roulette avec la souris ps/2 weel mouse cros$oft aprés 2/3 recherches je subis un gel d'écran
soyez prudent il y a peut-être des risques d'esplosion du moniteur...
-+- FM in GNU : la souris rit, la roulette ruse et tout explose -+-
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 ?
Exact.
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:
Je sais, merci. Mais ça n'est pas envisageable, parce que les fichiers ne doivent pas être bêtement concaténés. Ils doivent être modifiés, réarrangés, secoués, ...
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.
Pas envisageable. Ces fichiers changent très régulièrement, et peuvent atteindre plusieurs centaines de Mo chacun.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- quand j'utilise la roulette avec la souris ps/2 weel mouse cros$oft aprés 2/3 recherches je subis un gel d'écran soyez prudent il y a peut-être des risques d'esplosion du moniteur... -+- FM in GNU : la souris rit, la roulette ruse et tout explose -+-
Jean-Marc Bourguet
Erwann ABALEA writes:
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sur Solaris au moins, voir man dlsym, chercher RTLD_NEXT.
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:
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais
pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de
libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il
n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de
LD_PRELOAD?
Sur Solaris au moins, voir man dlsym, chercher RTLD_NEXT.
A+
--
Jean-Marc
Site de usenet-fr: http://www.usenet-fr.news.eu.org
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sur Solaris au moins, voir man dlsym, chercher RTLD_NEXT.
A+
-- Jean-Marc Site de usenet-fr: http://www.usenet-fr.news.eu.org
Stephane Chazelas
2003/10/28, 22:25(+00), Thomas Nemeth: [...]
Effectivement. J'ai cité userfs car je l'avais en mémoire et dans mes bookmarks.
userfs et newuserfs sont morts.
Ya:
UVFS (http://www.sciencething.org/geekthings/UVFS_README.html) et FUSE (sourceforge)
qui semblent plus vivant (au moins c'est pour du 2.4)
On Wed, 29 Oct 2003 08:41:12 +0100, Erwann ABALEA wrote:
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sous Linux tu peux appeller la fonction __libc_open() Je pense que toutes les fonctions doivent être accessible suivant ce schéma mais je n'en suis pas sur. Sous Solaris (avec GNU gcc/ld) il y aussi ces symboles/fonctions avec des underscores...
On Wed, 29 Oct 2003 08:41:12 +0100, Erwann ABALEA wrote:
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais
pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de
libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il
n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de
LD_PRELOAD?
Sous Linux tu peux appeller la fonction __libc_open()
Je pense que toutes les fonctions doivent être accessible suivant ce
schéma mais je n'en suis pas sur. Sous Solaris (avec GNU gcc/ld) il y
aussi ces symboles/fonctions avec des underscores...
On Wed, 29 Oct 2003 08:41:12 +0100, Erwann ABALEA wrote:
On Tue, 28 Oct 2003, Erwann ABALEA wrote:
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, ...).
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sous Linux tu peux appeller la fonction __libc_open() Je pense que toutes les fonctions doivent être accessible suivant ce schéma mais je n'en suis pas sur. Sous Solaris (avec GNU gcc/ld) il y aussi ces symboles/fonctions avec des underscores...
Erwann ABALEA
On 29 Oct 2003, Jean-Marc Bourguet wrote:
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).
Merci, c'est bon à savoir.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je n'est plus besoin des headers, j'ai verifie sur dejanew, tous est ok. On c'est fait avoir par les dinos. Il n'y a plus qu'a chercher une solution constructive aux votes destructifs des dinos. -+- JL in : Guide du Neueu Usenet - Mode Calimero ON -+-
On 29 Oct 2003, Jean-Marc Bourguet wrote:
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).
Merci, c'est bon à savoir.
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Je n'est plus besoin des headers, j'ai verifie sur dejanew, tous est
ok. On c'est fait avoir par les dinos. Il n'y a plus qu'a chercher une
solution constructive aux votes destructifs des dinos.
-+- JL in : Guide du Neueu Usenet - Mode Calimero ON -+-
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).
Merci, c'est bon à savoir.
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Je n'est plus besoin des headers, j'ai verifie sur dejanew, tous est ok. On c'est fait avoir par les dinos. Il n'y a plus qu'a chercher une solution constructive aux votes destructifs des dinos. -+- JL in : Guide du Neueu Usenet - Mode Calimero ON -+-
Erwann ABALEA
On 29 Oct 2003, Jean-Marc Bourguet wrote:
Erwann ABALEA writes:
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sur Solaris au moins, voir man dlsym, chercher RTLD_NEXT.
Exact, je viens de vérifier sous Solaris 8 et 9. Merci bien. Il semblerait qu'un embryon de cette fonctionnalité soit également disponible sous Linux, même si la page de man n'en cause pas (voir /usr/include/dlfcn.h). Sans lancer de troll, les pages de man de Solaris sont quand même meilleures... Je sais, si je veux que ça s'améliore, j'ai qu'à participer. ;)
Au pire, si le RTLD_NEXT n'est pas supporté, ça doit pouvoir être simulé...
-- 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 29 Oct 2003, Jean-Marc Bourguet wrote:
Erwann ABALEA <erwann@abalea.com> writes:
Petite question... Si je redéfinit la fonction open(), comment je fais
pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de
libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il
n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de
LD_PRELOAD?
Sur Solaris au moins, voir man dlsym, chercher RTLD_NEXT.
Exact, je viens de vérifier sous Solaris 8 et 9. Merci bien.
Il semblerait qu'un embryon de cette fonctionnalité soit également
disponible sous Linux, même si la page de man n'en cause pas (voir
/usr/include/dlfcn.h).
Sans lancer de troll, les pages de man de Solaris sont quand même
meilleures... Je sais, si je veux que ça s'améliore, j'ai qu'à participer.
;)
Au pire, si le RTLD_NEXT n'est pas supporté, ça doit pouvoir être
simulé...
--
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 -+-
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sur Solaris au moins, voir man dlsym, chercher RTLD_NEXT.
Exact, je viens de vérifier sous Solaris 8 et 9. Merci bien. Il semblerait qu'un embryon de cette fonctionnalité soit également disponible sous Linux, même si la page de man n'en cause pas (voir /usr/include/dlfcn.h). Sans lancer de troll, les pages de man de Solaris sont quand même meilleures... Je sais, si je veux que ça s'améliore, j'ai qu'à participer. ;)
Au pire, si le RTLD_NEXT n'est pas supporté, ça doit pouvoir être simulé...
-- 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 -+-
Erwan David
Erwann ABALEA écrivait :
On 29 Oct 2003, Jean-Marc Bourguet wrote:
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).
Merci, c'est bon à savoir.
Si tu pars dans cette direction là regarde cfs, le backend chiffrement/déchiffrement ne t'intéressera pas, mais la partie serveur NFS sera peut-être réutilisable :
http://www.crypto.com/software/
-- Erwan
Erwann ABALEA <erwann@abalea.com> écrivait :
On 29 Oct 2003, Jean-Marc Bourguet wrote:
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).
Merci, c'est bon à savoir.
Si tu pars dans cette direction là regarde cfs, le backend
chiffrement/déchiffrement ne t'intéressera pas, mais la partie serveur
NFS sera peut-être réutilisable :
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).
Merci, c'est bon à savoir.
Si tu pars dans cette direction là regarde cfs, le backend chiffrement/déchiffrement ne t'intéressera pas, mais la partie serveur NFS sera peut-être réutilisable :
http://www.crypto.com/software/
-- Erwan
Erwann ABALEA
On Wed, 29 Oct 2003, no wrote:
On Wed, 29 Oct 2003 08:41:12 +0100, Erwann ABALEA wrote:
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sous Linux tu peux appeller la fonction __libc_open() Je pense que toutes les fonctions doivent être accessible suivant ce schéma mais je n'en suis pas sur. Sous Solaris (avec GNU gcc/ld) il y aussi ces symboles/fonctions avec des underscores...
C'est normal, c'est le compilateur qui ajoute un '_' initial. Mais si j'essaye d'appeler _open(), c'est ma propre fonction que je vais trouver, et c'est pas bon.
Et chercher une fonction appelée __libc_open(), je ne pense pas que ce soit standard. Ou alors on fait comme Ford: "le client a le choix de la couleur, du moment que c'est noir". :)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- C>Faisons le point une bonne fois. tu m'as un peu irrité en affirmant C>que le point G n'existait pas. Je peux te le prouver si tu veux. Te fatigue pas, j'ai un clitoris qui fait l'affaire. -+- GL in Guide du Neuneu d'Usenet - Toutes options montées en série -+-
On Wed, 29 Oct 2003, no wrote:
On Wed, 29 Oct 2003 08:41:12 +0100, Erwann ABALEA wrote:
Petite question... Si je redéfinit la fonction open(), comment je fais
pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de
libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il
n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de
LD_PRELOAD?
Sous Linux tu peux appeller la fonction __libc_open()
Je pense que toutes les fonctions doivent être accessible suivant ce
schéma mais je n'en suis pas sur. Sous Solaris (avec GNU gcc/ld) il y
aussi ces symboles/fonctions avec des underscores...
C'est normal, c'est le compilateur qui ajoute un '_' initial. Mais si
j'essaye d'appeler _open(), c'est ma propre fonction que je vais trouver,
et c'est pas bon.
Et chercher une fonction appelée __libc_open(), je ne pense pas que ce
soit standard. Ou alors on fait comme Ford:
"le client a le choix de la couleur, du moment que c'est noir". :)
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
C>Faisons le point une bonne fois. tu m'as un peu irrité en affirmant
C>que le point G n'existait pas. Je peux te le prouver si tu veux.
Te fatigue pas, j'ai un clitoris qui fait l'affaire.
-+- GL in Guide du Neuneu d'Usenet - Toutes options montées en série -+-
On Wed, 29 Oct 2003 08:41:12 +0100, Erwann ABALEA wrote:
Petite question... Si je redéfinit la fonction open(), comment je fais pour appeler la vraie? Le seul truc que je vois, c'est faire un dlopen de libc, puis un dlsym sur open. Y'a pas plus propre? Je veux dire qu'il n'est pas possible de redéfinir 2 fois les mêmes fonctions à coup de LD_PRELOAD?
Sous Linux tu peux appeller la fonction __libc_open() Je pense que toutes les fonctions doivent être accessible suivant ce schéma mais je n'en suis pas sur. Sous Solaris (avec GNU gcc/ld) il y aussi ces symboles/fonctions avec des underscores...
C'est normal, c'est le compilateur qui ajoute un '_' initial. Mais si j'essaye d'appeler _open(), c'est ma propre fonction que je vais trouver, et c'est pas bon.
Et chercher une fonction appelée __libc_open(), je ne pense pas que ce soit standard. Ou alors on fait comme Ford: "le client a le choix de la couleur, du moment que c'est noir". :)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- C>Faisons le point une bonne fois. tu m'as un peu irrité en affirmant C>que le point G n'existait pas. Je peux te le prouver si tu veux. Te fatigue pas, j'ai un clitoris qui fait l'affaire. -+- GL in Guide du Neuneu d'Usenet - Toutes options montées en série -+-
