IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Traduction LDD3 Discussion :

Chapitre 4 : Debugging Techniques partie 1


Sujet :

Traduction LDD3

  1. #1
    Rédacteur
    Avatar de Arnaud F.
    Homme Profil pro
    Développeur COBOL
    Inscrit en
    août 2005
    Messages
    5 183
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 34
    Localisation : France

    Informations professionnelles :
    Activité : Développeur COBOL
    Secteur : Finance

    Informations forums :
    Inscription : août 2005
    Messages : 5 183
    Points : 8 870
    Points
    8 870
    Par défaut Chapitre 4 : Debugging Techniques partie 1
    Mon anglais à fait des siennes et voici un texte à relire techniquement en P.J

    Je tiens à préciser qu'y a des termes que je ne savais pas du tout comment traduire, donc faut "bien" relire

    Fichiers attachés Fichiers attachés
    C'est par l'adresse que vaut le bûcheron, bien plus que par la force. Homère

    Installation de Code::Blocks sous Debian à partir de Nightly Builds

  2. #2
    Futur Membre du Club
    Inscrit en
    janvier 2008
    Messages
    5
    Détails du profil
    Informations forums :
    Inscription : janvier 2008
    Messages : 5
    Points : 5
    Points
    5
    Par défaut Chapitre 4 : Debugging Techniques partie 1
    salut Buchs
    Je suis vos efforts pour traduire LDDIII depuis quelques semaines, les drivers sous Linux m'intéressant de très près, il serait peut etre temps que j'apporte ma contribution à votre projet de traduction, donc voilà j'ai relu ta traduction:

    en gras noir j'ai mis les corrections dont je suis sûr
    en gras noir entre parenthèses j'ai mis les mots que j'utiliserai (une traduction peut etre sujette à des discussions infinies je te donne mon avis mais si tu hésites gardes tes tournures)
    en bleu mes commentaires (je ne suis pas un littéraire je donne mon avis sans aucunes prétentions)

    Une fois de plus mes corrections sont discutables. J'espère en tout cas qu'elles seront intelligibles (et pas trop bourrées elles même de fautes )

    Je profites de l'occasion pour proposer mon aide. Toi qui a une meilleure visibilité sur le projet n'hésites pas à orienter mes efforts dans un sens qui serait utile que ce soit de la relecture ou de la traduction (le chapitre 5 m'intéresse bien, s'il n'est pas pris je veux bien m'y "coller")

    Voilà en tout cas merci pour l'initiative et vos efforts.
    A+



    <section id="VI">
    <title>Techniques de déboguage</title>
    <paragraph>
    La programmation du noyau apporte ses propres défis de déboguage. Le code du noyau ne peut pas être facilement exécuté avec un debogueur, il ne peut pas être facilement tracé non plus car que c'est un jeu de fonctionnalités
    non liées à un processus spécifique. Des erreurs de code du noyau peuvent aussi être extrêmement dures à reproduire et peuvent détruire le système entier avec eux, détruisant ainsi beaucoup d'indices qui pourrait être utilisés pour les traquer.</paragraph>
    <paragraph>
    Ce chapitre introduit des techniques que vous pouvez utiliser pour contrôler le code du noyau et tracer les erreurs sous certaines circonstances.</paragraph>


    <section id="VI-1">
    <title>Support de déboguage dans le noyau</title>

    <paragraph>
    Dans le chapitre 2, nous (vous) avons recommandé de construire et d'installer votre propre noyau plutôt que de se précipiter
    à installer le noyau fourni avec votre distribution. L'une des plus importantes raisons d'utiliser votre propre noyau
    est que les développeurs du noyau ont (mis au point) construit plusieurs fonctionnalités de déboguage dans le noyau lui-même.
    Ces fonctionnalités peuvent créer des sorties spéciales et des performances moindres,
    ainsi ils ont tendance à ne pas les activer dans les noyaux qui sont destinés à être mis en production par les distributeurs.

    Il me semble que sur la phrase précédente soit tu mets "ils/les distributeurs ont tendances à ne pas activer ces options dans leur versions commerciales", soit "elles/ces options ont tendance à ne pas être activées dans les noyaux fournis par des distributeurs." perso je pencherai pour la seconde formulation


    Cependant, en tant que développeur de noyau, vous avez d'autres priorités et (vous) accepterez bien volontiers la couche supérieure du support de déboguage du noyau.</paragraph>


    <paragraph>
    Ici, nous listons les options de configurations qui devraient être activées pour les noyaux utilisés à des
    fins de développement. Sauf contre-indication de notre part dans la suite, toutes ces options sont
    situées dans le menu "kernel hacking" et ce quelque soit l'outil de configuration choisi.</paragraph>

    <imgtext type="warning">
    Notez que certaines de ces options ne sont pas supportées par toutes les architectures.
    </imgtext>


    <liste>


    <element><b>CONFIG_DEBUG_KERNEL :</b>
    Cette option rends juste d'autres options de déboguage disponibles. Elle devrait être activée mais ne rendra pas,
    par elle-même, toutes les options disponibles.</element>


    <element><b>CONFIG_DEBUG_SLAB :</b>
    Cette option est cruciale et permet plusieurs types de vérifications dans les fonctions d'allocation mémoire du noyau.
    Avec cette vérification d'activée, il est possible de détecter une sur-utilisation de la mémoire ainsi que les erreurs d'oublis d'initialisation de celle-ci. Chaque octet de la mémoire allouée est mise à <i>0xa5</i>
    avant d'être remise par l'appeleur qui lui la met à <i>0x6b</i> quand elle est libérée.

    pour la phrase précédente j'aurai dit: "Chaque octet de la mémoire allouée est mise à <i>0xa5</i> avant d'être donnée à l'appeleur et ensuite mise à <i>0x6b</i> quand elle est libérée"


    Si vous avez déjà vu l'un ou l'autre de ces motifs "poisons" se répéter à la sortie de votre pilote (ou bien dans un listing), vous connaîtrez exactement quel genre d'erreur chercher. Quand le déboguage est activé, le noyau place également des valeurs de guarde spéciales avant et après chaque objet mémoire alloué. Si ces valeurs ne changent jamais, le noyau sait que quelqu'un a sur-utilisé la mémoire et il se plaint bruyamment. Diverses vérifications pour des erreurs plus obscures sont aussi activées.</element>


    <element><b>CONFIG_DEBUG_PAGEALLOC :</b>
    Des pages entières sont enlevés de l'espace mémoire du noyau quand il est libéré. Cette option peut ralentir significativement les choses, mais il peut aussi indiquer rapidement certaines erreurs de corruption de mémoire.</element>

    <element><b>CONFIG_DEBUG_SPINLOCK :</b>
    Avec cette option d'activée, le noyau (repère) attrape les opérations sur des verrous tournants non initialisés et différentes autres erreurs (comme ouvrir un verrou deux fois).</element>

    <element><b>CONFIG_DEBUG_SPINLOCK_SLEEP :</b>
    Cette option permet une vérification pour les tentatives de dormir (alors qu'un verrou tournant est détenu ) en tenant un verrou tournant.

    En fait, il se plaint si vous appelez une fonction qui pourrait potentiellement dormir, même si l'appel en question ne dormirait pas.</element>

    <element><b>CONFIG_INIT_DEBUG :</b>
    Les choix marqués avec <i>__init</i> (ou <i>__initdata</i>) sont écartés (après) par l'initialisation du système

    Là par contre ma très modeste connaissance des drivers linux me permet de penser que la phrase serait plus juste dite de la manière suivante:
    Les choix marqués avec <i>__init</i> (ou <i>__initdata</i>) sont écartés après l'initialisation du système


    ou le chargement des modules. Cette option permet le contrôle du code qui tente davoir accès à la mémoire d'initialisation
    après que l'initialisation soit complète.</element>


    <element><b>CONFIG_DEBUG_INFO :</b>
    Cette option implique que le noyau soit construit avec toutes les informations
    de déboguage incluses. Vous aurez besoin de ces informations si vous voulez déboguer le noyau avec <i>gdb</i>.
    Vous pouvez aussi vouloir permettre <b>CONFIG_FRAME_POINTER</b> si vous prévoyez d'utiliser <i>gdb</i></element>

    <element><b>CONFIG_MAGIC_SYSRQ :</b>
    Permet les touches "magic SysRq" (touches magiques). Nous aborderons ces touches dans la section <b><i><u>"Accrochage système"</u></i></b> plus tard dans ce chhapitre.</element>


    <element><b>CONFIG_DEBUG_STACKOVERFLOW &amp; CONFIG_DEBUG_STACK_USAGE :</b>
    Ces options peuvent aider à traquer le débordement de la pile du noyau. Un signe certain de ce débordement de la pile est un listing sans aucun tri raisonnable des traces. La première option ajoute des contrôles explicites de débordement de pile au noyau, la seconde implique que le noyau contrôle l'utilisation de la pile et réalise quelques statistiques accessibles grâce aux touches magiques (SysRq).</element>


    <element><b>CONFIG_KALLSYMS :</b>
    Cette option (sous "General setup/Standard features" implique que les informations des symboles du noyau sont construites dans le noyau, cela est permis par défaut. Les informations de symbole sont utilisées dans le contexte du déboguage. Sans elles, le listing peut vous donner la pile d'exécution en hexadécimal seulement, ce qui n'est pas très utile.</element>


    <element><b>CONFIG_IKCONFIG &amp; CONFIG_IKCONFIG_PROC :</b>
    Ces options (situées dans le menu "General setup") impliquent l'état de configuration total du noyau a être construit dans le noyau et a être disponible via <i>/proc</i>.

    moi j'aurais dit: Ces options (situées dans le menu "General setup") impliquent la construction dans le noyau de l'état de configuration et le (l'état de configuration) rendent disponible via /proc


    La plupart des développeurs du noyau connaissent la configuration
    qu'ils ont utilisé
    et n'ont pas besoin de ces options (qui rendent le noyau plus lourd). Bien qu'elles peuvent être
    utiles si vous êtes en train d'essayer de déboguer un problème dans un noyau construit par quelqu'un d'autre.</element>


    <element><b>CONFIG_ACPI_DEBUG :</b>
    Sous "Power management/ACPI", cette option active la verbosité des informations de déboguage de l'ACPI (Advanced Configuration and Power Interface) qui peuvent être utiles si vous suspectez un problème relatif à l'ACPI


    <element><b>CONFIG_DEBUG_DRIVER :</b>
    Sous "Device drivers". Active les informations de déboguage dans le coeur du pilote, ce qui peut être utile pour traquer les problèmes dans la partie inférieure du code. Nous allons regarder dans le coeur du pilote au chapitre 14.</element>


    <element><b>CONFIG_SCSI_CONSTANTS :</b>
    Cette option, située sous "Device drivers/SCSI device support" construit les informations pour la verbosité des message d'erreurs SCSI. Si vous travaillez sur un pilote SCSI, vous aurez probablement besoin de cette option.</element>


    <element><b>CONFIG_INPUT_EVBUG :</b>
    Cette option (sous Device drivers/Input device support) active l'enregistrement verbeux des événements d'entrées.
    Si vous travaillez sur un pilote pour un périphérique d'entrée, cette option peut être utile. Soyez conscient des implications de sécurité de cette option, cependant , elle enregistre tout ce que vous tapez, y compris vos mots de passe.</element>

    au sens littéral cela me semble bon however=cependant mais il me semble qu'un truc du style "soyez conscient des problèmes de sécurité car elle enregistre tout ce que vous tapez, y compris vos mots de passe" serait plus logique.


    <element><b>CONFIG_PROFILING :</b>
    Cette option est située sous "Profiling support". Le profilage est normalement utilisé pour l'amélioration des performances du système, mais il peut aussi être utile pour traquer récursivement certains acrochages système et problèmes apparentés.</element>

    </liste>


    <paragraph>Nous allons revisiter quelques unes des options citées ci-dessus quand nous aborderons les différentes manières de traquer les problèmes liés au noyau. Mais tout d'abord, nous allons regarder à la technique classique
    de déboguage : les instructions d'impression.</paragraph>
    </section>

Discussions similaires

  1. Chapitre 3 : char drivers partie 3
    Par Michaël dans le forum Traduction LDD3
    Réponses: 2
    Dernier message: 22/09/2008, 14h41
  2. Chapitre 3 : char drivers partie 5
    Par Michaël dans le forum Traduction LDD3
    Réponses: 4
    Dernier message: 22/09/2008, 12h12
  3. Chapitre 3 : Char drivers partie 2
    Par Arnaud F. dans le forum Traduction LDD3
    Réponses: 4
    Dernier message: 31/08/2008, 12h29
  4. Chapitre 3 : Char drivers partie 1
    Par Arnaud F. dans le forum Traduction LDD3
    Réponses: 14
    Dernier message: 28/08/2008, 20h52
  5. Chapitre 3 : Chars drivers partie 4
    Par Arnaud F. dans le forum Traduction LDD3
    Réponses: 3
    Dernier message: 18/08/2008, 11h08

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo