Journal procfs, limitation du système de fichiers, PATH_MAX

Posté par  .
Étiquettes : aucune
0
15
mai
2004
cher journal, je suis face à un petit problème. j'ai besoin de lire des choses dans /proc

pour ça j'ai une fonction générique, qui prend en paramètre un chemin, un pid et un buffer

genre

read_proc(char *buffer, const char *path, pid_t p)

qui est appelée de part et d'autres comme suivant

read_proc(buffer, "/proc/%d/stat", p);

path étant toujours une chaine littérale


jusque là pas de problème. en fait ce qui me gène c'est que dans read_proc, pour des raisons d'efficacité, je n'utilise pas d'allocation dynamique
je fais donc
char name[CONSTANTE];
sprintf(name, path, p);

pour ensuite ouvrir le fichier

jusqu'à présent, CONSTANTE vaut 4096. en quête de portabilité, en lisant le man de getwd, j'ai découvert une constante PATH_MAX qui vaut également 4096. mais le man en déconseille l'usage.

j'ai également constaté que sur ma machine, le chemin le plus long dans mon /proc faisait 61caractères... je suis donc bien loin des 4096

donc en fait ma question est double : je suis en quête de portabilité et d'une petite amélioration de performances. y a t il quelque chose qui puisse me renseigner de manière portable sur le MAX_PATH de procfs ?

sinon, je vais devoir me tourner vers des macros...

  • # Portabilité ?

    Posté par  . Évalué à 1.

    En quête de portabilité pourquoi ?

    Excuse moi si je me trompe mais procfs est spécifique à linux. La plupart des autres UNIX like n'en ont pas ou alors selon leur propre format. Donc la portabilité de la chose semble plutôt limitée ou j'ai loupé quelque chose.

    Si tu n'a qu'a lire lles /proc/*/stat c'est sur que tu vas avoir a atteindre les 4096 mais en même temps j'ai relu deux fois et ou tu veux en venir n'est pas clair :-)
    Pour les performances bin au pire tu gapsille un peu de mémoire.

    • [^] # Re: Portabilité ?

      Posté par  . Évalué à 2.

      1) on voit que t'as jamais fréquenté que des procfs sous X86 ... et comme je sais pas sur quoi je tombe, j'ai pas envie de faire n'importe quoi. 4096c ça me parait inatteignable, mais ça ne prouve rien. j'aimerais bien baisser cette limite mais jusqu'à combien ...
      2) non justement, si j'ai fait une fonction, c'est justement parce que j'ai beaucoup de fichiers à lire ici et là
      3) et bien justement, ça commence à me gaver : j'ai 20 fonctions qui sont toutes au dessus de 12Ko d'usage de pile alors que l'exécution montre que 400o suffirait. je ne veux pas faire de gaspillage, je veux faire du nettoyage justement et ajuster un ensemble de choses : mon code est truffé de constantes arbitraires souvent déconnectées de la réalité. je cherche à valider tout ça

      • [^] # Re: Portabilité ?

        Posté par  . Évalué à 3.

        Pour ce qui est de la longueur maximale de /proc/%d/stat; tu peux facilement le calculer sachant la valeur maximale que pid_t peut prendre ou en utilisant le sysctl KERN_PIDMAX.

        Pour ce qui est de la mémoire, tu peux utiliser un buffer global (beurk beurk). Certes, il faut voir que ton programme n'est pas (ou ne sera pas) multithreadé sinon bonjours les ennuis. Dans ce cas là, tu peux envisager d'avoir une structure par thread qui te sert à stocker un environnement et que tu passes par paramètre à chaque fonction.

        • [^] # Re: Portabilité ?

          Posté par  . Évalué à 1.

          - déjà merci, je ne connaissais pas l'existence de KERN_PIDMAX
          - pour la dernière fois, je ne lis pas que /proc/[pid]/stat
          - bien essayé, mais faut absolument que ça soit réentrant (bibliothèque oblige)

          et bien je vois que mon magique 4096 a de beaux jours devant lui ...

          • [^] # Re: Portabilité ?

            Posté par  (site web personnel) . Évalué à 1.

            - bien essayé, mais faut absolument que ça soit réentrant (bibliothèque oblige)

            Et bien alors oublie tout de suite ce que tu fait a present, si tu veut faire du reentrant regarde les fonctions fournies par le glibc terminée en _r(), elles demandent toutes le buffer et sa taille, car il n'est pas possible de concilier efficacement et de maniere propre le multi-thread, les buffers et les allocations dans les fonctions.

            Ps: est tu certain d'avoir besoin de consulter le /proc pour faire ce que tu veut ?
            Normalement c'est plutot reservé aux scripts, les programmes compilés faisant appel aux syscall correspondants.

      • [^] # Re: Portabilité ?

        Posté par  . Évalué à 2.

        1) on voit que t'as jamais fréquenté que des procfs sous X86

        Bin dans ton journal tu ne parles que de lire stat des processsus. On ne peut pas deviner ce que tu veux en faire non plus.

        Pour la taille maxi de procfs en effet c'est difficillement calculable.

        3) et bien justement, ça commence à me gaver : j'ai 20 fonctions qui sont toutes au dessus de 12Ko d'usage de pile alors que l'exécution montre que 400o suffirait. je ne veux pas faire de gaspillage,

        Tu viens de decouvrir la magie de linux et son tout /proc :-)
        Le jour ou ils comprendront que /procfs c'est bien pour faire des scripts shell mais pas plus ils se mettront peut a fournir des fonction pour les vrais programmes... Voir les BSD par exemple...

  • # bientot ici: un titre

    Posté par  (site web personnel) . Évalué à 1.

    > je suis en quête de portabilité et d'une petite amélioration de performances.

    je suis pas sûr qu'il y ait quelque chose a gagner en perf, la lecture de procfs est monstrueusement couteuse en temps cpu malheureusement. Y'a qu'a voir comment un pauvre "top" bouffe du cpu :-/

  • # snprintf

    Posté par  (site web personnel) . Évalué à 2.

    De toutes façons, il faut que tu remplaces sprintf par snprintf.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.