Journal modification de la structure de /proc/meminfo avec les noyaux 2.6

• # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

  Posté par Jerome Herman le 19 décembre 2003 à 18:44. Évalué à 5.

  

  Dans un premeir temps lfair eune recherche dans la mailing liste kernel dev pour essayer de trouver le pourquoi.
  
  Dans un deuxieme temps envoyer un mail a quiconque a fait le smodifs pour lui demander pourquoi. Generalement il y a le nom et l'adresse email dans le fichier source, sinon retour sur la kernel dev ou le CVS pour voir qui joue avec cette lib.
  
  Kha

• # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

  Posté par M le 19 décembre 2003 à 19:22. Évalué à 1.

  

  en fait, y a pas mal de bibliothèques qui cassent à cause de ça, au moment de la lecture et analyse de ce fichier.
  Comme quoi ?
  
  en tout cas free n'a pas de pb...
  
  Et puis pourquoi tes bibliothèques sont cassé : si c'etait bien programer ça devrait utiliser que les lignes utiles de meminfo (et les 3 premieres n'apportaient pas grand chose ?)

  • [^] # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

    Posté par TazForEver le 19 décembre 2003 à 19:33. Évalué à 4.

    

    glibtop par exemple. (au coeur de gdesklets et de nombreuses applications GNOME)
    ce que tu dis est ridicule. les trois premières lignes de meminfo contiennent les informations en octets destinées à ce genre de programme. le reste est plus destiné à être lisible (affichage en Ko). ces 3 lignes étaient sans doute là bien avant les autres.
    y a pas de bien programmer ... si tu changes une spécification, ça fout forcément des trucs en l'air. si le noyau fournit des informations, il faut s'attendre à ce que les gens les utilisent !
    
    bref, je suis pas avancé ... je commence mes recherches

    • [^] # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

      Posté par Christophe Fergeau le 20 décembre 2003 à 11:17. Évalué à 2.

      

      > glibtop par exemple. (au coeur de gdesklets et de nombreuses applications GNOME)
      
      C'est corrigé je pense http://www.advogato.org/person/hadess/diary.html?start=296(...)

  • [^] # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

    Posté par Ramso le 20 décembre 2003 à 09:52. Évalué à 1.

    

    et xosview ne marche plus :/

• # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

  Posté par icyfemur le 19 décembre 2003 à 19:44. Évalué à 6.

  

  Y a vraiement des choses que j'ai du mal a comprendre des fois dans Linux...
  
  Pourquoi n'existe il pas des libraries « d'appels systemes » permettant de récupérer ce genre d'infos ? Cela éviterai d'être dépendant un format de fichier, avec un parsing pénible qui doit prendre du temps...
  
  C'est le meme genre de choses que le bug qu'il y avait eu avec kdiskfree, qui plantait car il parsait le résultat de « df », mais avait oublié de mettre la locale « C », et comme mon systeme est localisé français, ca le perdait complètement...
  
  Je trouve que s'appuyer sur des résultat de commande ou des mise en forme de fichier est une méthode bien étrange, peu pérène, et pénible à mettre en oeuvre... tout devrait être, à mon avis, disponible via des libs...

  • [^] # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

    Posté par Troy McClure (site web personnel) le 19 décembre 2003 à 19:56. Évalué à 4.

    

    et au lieu de lignes manquantes dans un fichier, on aurait des fonctions dont les noms /le type des arguments changeraient, et donc des dépendances sur les versions des noyaux etc . Moi j'aime bien l'idée de tout avoir dans /proc

  • [^] # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

    Posté par daggett le 20 décembre 2003 à 02:56. Évalué à 3.

    

    Et encore, ça pourrait être pire: /proc en XML :)
    http://bitmover.com/pipermail/lmbench-users/2003-November/thread.ht(...)

• # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

  Posté par mickabouille le 20 décembre 2003 à 10:37. Évalué à 1.

  

  > et si possible, revenir à l'ancienne forme ?
  
  A mon avis, ny compte pas trop. Le contenu de proc a eacoup changé, ça a été décidé et accepté. Et ce genre de modification est regardé de près. Si le patch a été acepté, c'est que quelqu'un (peut être Linus) a pensé que le gain était supérieur à l'incompatibilité introduite.
  Sans parler que pour le moment, le 2.6.à est encore en correction de bogues uniquement!

• # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

  Posté par Pierre Tramo le 20 décembre 2003 à 11:42. Évalué à 3.

  

  C'est aujourd'hui le plus gros défaut de linux : une incapacité chronique à assurrer une compatibilité ascendante. Les développeurs ne pensent absolument pas que certaines personnes essayent de batir des logiciels destinés à fonctionner pendant des années, et à chaque mise à jour importante, tout est modifié. Entre les ABI mouvantes de gcc, les symboles qui disparaissent du jour au lendemain dans la glibc ou la libstdc++, c'est impossible de construire une application pouvait être livré fonctionnelle sur différentes plateformes.
  
  Aujourd'hui, non seulement linux n'est pas prêt pour le desktop, mais n'est pas prêt pour être pris au sérieux. Ras le bol de cet OS pour étudiants boutonneux et associal, je retourne sous des OS qui ne prennent pas leur client pour un codeur fou.

• # Re: modification de la structure de /proc/meminfo avec les noyaux 2.6

  Posté par hicham le 20 décembre 2003 à 12:52. Évalué à 4.

  

  libgtop était mal codée. Au lieu de parser le conenu de /proc/meminfo, elle utilisait le numero des lignes pour arriver aux differents champs. L'ajout d'une nouvelle entrée comme c'est le cas pour le 2.6 "fausse le calcul". Ils ont corrigé ça dans la branche HEAD de cvs.

Suivre le flux des commentaires

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