Linux Device Drivers

Posté par  . Édité par Benoît Sibaud. Modéré par trollhunter.
Étiquettes :
0
7
jan.
2001
Linux

Extrait: « Qui ne s'est jamais dit en présence d'un matériel assez simple mais non encore supporté: "Il faut que je me code le driver ça ne doit pas être si sorcier !". En effet, si l'on a accès aux bonnes informations cette aventure peut s'avérer très constructive et enrichissante, comme vous le prouve cet ouvrage. »

Sommaire

Linux Device Drivers
Auteur : Alessandro Rubini
Éditeur : O'REILLY
ISBN : 1-56592-292-1
Pages 421
Prix : Constaté : 255F
Rédacteur : trollhunter

Couverture

Le premier chapitre vous présente tout naturellement les bases du noyau et les subtilités de licence s'appliquant au logiciel. Puis, dès le second chapitre l'on plonge directement dans le sujet avec la présentation des modules. Le troisième chapitre est lui consacré au bases des char drivers avec les opérations de lecture/écriture.

Arrivé à ce point de l'ouvrage, il est fort possible que vous ayez commencé à expérimenter dans votre coin et que vous ayez déjà quelques petits soucis, cela tombe bien, l'auteur vous donne les ficelles pour déboguer vos petits modules.

Puis l'on replonge dans le monde des char drivers avec la présentation d'ioctl, des E/S bloquantes et de la gestion des accès sur un fichier de périphérique.

Lorsque l'on rédige des drivers, la gestion du paramètre temps est très importante puisqu'elle vous permet non seulement d'accéder au temps présent, de retarder certaines opérations pendant un certain temps ( cas par exemple de l'attente d'une vitesse de rotation constante pour certains périphériques ), aussi un chapitre entier y est constaté vous montrant les différentes manières d'y accéder, la gestion des files d'ordonnancement.

Un autre paramètre très important est la gestion de la mémoire, avec, dans le chapitre suivant la présentation de kmalloc, vmalloc et get_free_page.

Maintenant que la partie soft commence à vous être familière vous allez pouvoir aborder la partie hard, cette partie commence doucement avec la présentation du port favori des lecteurs du Coffee mini HOWTO : le port parallèle. Puis l'on passe très vite sur les cartes ISA 1M, PCI, et l'accès en mode texte au buffer video.

Le neuvième chapitre est dédié à la gestion des interruptions avec l'implémentation d'un mini gestionnaire d'interruptions. La gestion de la concurrence fait l'objet d'un soin particulier.

Le chapitre suivant est consacré à l'utilisation judicieuse des types de données; en effet lorsque l'on désire écrire un driver portable il faut faire très attention à la taille des différents types, sinon des surprises vous attendent.

Puis l'on revient sur la modularisation et kerneld, vous y apprendrez le support des versions dans vos modules ainsi que la persistence entre deux chargements/déchargement.

Cet ouvrage ayant commencé par vous présenter les drivers caractères, le douzième chapitre vous présente les pilotes en mode bloc. À l'issue de ce chapitre des aspects tels la gestion des partitions par le kernel n'auront plus de secrets pour vous.

Un petit retour sur la mémoire dans le chapitre suivant puisque l'on vous présente MMAP et les accès DMA.

Linux et réseau étant souvent associé, vous apprendrez les bases des gestionnaires réseau.

Enfin, vous avez tout naturellement droit à un chapitre où les bus vous sont présentés. L'accent est particulièrement mis sur le bus PCI et l'on vous parle un peu de MCA, EISA, VLB et Sbus.

Puis vous aurez droit à un chapitre intitulé physical layout of the Kernel Source où A. Rubini vous explique où trouver les différents sous ensembles du noyau et vous donne un petit aperçu du boot des PC, Alpha et SPARC.

Le 17ème et dernier chapitre est quand à lui consacré aux derniers développements par exemple les macros permettant les conversions big endian little endian, ces macros introduites avec le 2.1.10 sont standards sur tous les kernels >= 2.2.x .

Parmi les nombreux points que j'aime dans cet ouvrage d'introduction à l'écriture des pilotes pour le noyau il faut signaler le style de l'auteur qui aide à faire passer les difficultés de l'entreprise, de plus la structure des chapitres avec la petite partie introductive servant à placer le sujet, les explications très claire, le code et les sorties d'écran ou les dumps permettent de se faire une petite idée. En outre il faut signaler la clarté des schémas d'illustration que ce soit des schémas illustrant un brochage ou une structure de données. Enfin la section Quick Reference permet de bien synthétiser les connaissances acquises au cours du chapitre, et rappellent dans quel fichier sont déclarés les fonctions vues au cours de ce chapitre.

Par contre il y a quelques petits regrets, mais ils sont surtout dus à l'âge du livre (février 1998): cet ouvrage se base sur les noyaux 2.0 et 2.1.10, l'on ne parle pas du tout de l'USB, et la section sur le bus Sbus aurait mérité beaucoup plus d'explications d'autant plus que l'auteur possède une SPARC et que dans la section initialisation du 16ème chapitre l'amorçage d'une SPARC est très bien expliqué.

Mais en dehors de ce petit détail, les quelques 400 pages de cet ouvrage sont vraiment très intéressantes. À signaler un autre ouvrage, qui est une petite initiation à l'écriture de modules pour le noyau, c'est le [Linux Kernel Module Programming guide]((http://linuxdoc.org/LDP/lkmpg/mpg.html).

Enfin pour compléter le driver l'on pourra toujours se reporter à l'ouvrage de R.Stones où vous apprendrez à créer les bibliothèques de développement autour de votre pilote, à utiliser les services de syslogd et enfin à rédiger la page man expliquant le tout.

Table des matières

  1. An introduction to the Linux Kernel
  2. Building and running modules
  3. Char Drivers
  4. Debugging techniques
  5. Enhanced Char Driver Operations
  6. Flow of time
  7. Getting hold of Memory
  8. Hardware Management
  9. Interrupt Handling
  10. Judicious use of Data Types
  11. Kerneld and advanced Modularization
  12. Loading Block Drivers
  13. Mmap and DMA
  14. Network Drivers
  15. Overview of Peripheral Buses
  16. Physical Layout of the kernel Source
  17. Recent Developments
  18. Index

Références

Exemples sur le web de ce titre : ftp://ftp.ora.com/pub/examples/linux/drivers/ (NdM: site disparu et non archivé sur Web Archive, et http://examples.oreilly.com/pub/examples/linux/drivers ne les as pas non plus)

Pour la programmation Linux.

Aller plus loin

  • # Cool mais

    Posté par  . Évalué à 1.

    Dommage que le probleme, ce soit justement de les trouver, ces informations. C'est déjà arrivé à quelqu'un ? Parce qu'en général, les constructeurs ne répondent pas aux emails demandant des specs, (ou un tres froid et tres bref: "nous ne supportons que Microsoft Windows") et le ReverseEnginering n'est pas à la portée de tous (et je vois pas pourquoi sous pretexte qu'on n'utilise pas Microsoft, on devrait perdre notre temps à tout retrouver nous-meme !)
    • [^] # Re: Cool mais

      Posté par  . Évalué à 1.

      C'est assez juste, mais je pense que certains constructeurs sont prêts à donner les spécificités de leurs matériel, ça améliorerait leur image de marque, leur ouvrirait un nouveau marché et leur épargnerait le coût du développement du driver.
      Pour ma part, ça fait longtemps que j'attends ça et je vais courir me le procurer :)
    • [^] # Re: Cool mais

      Posté par  . Évalué à 1.

      maintenant pas mal de constructeur donne leur spec.
      Je te conseille de chercher sur les sites web des constructeurs tu t'apercevra que certains on les specifications de leur materiel (en .pdf)

      Tab
      • [^] # Re: Cool mais

        Posté par  . Évalué à 1.

        Merci de cette remarque super intelligente de ta part. Si je dis que j'ai du mal a trouver des infos sur tel ou tel truc, c'est que _a priori_, j'ai déjà regardé sur leur site web...

        Demande aux développeurs de tous les trucs un peu "unifiés" (genre Sane, gphoto, Livid, Linmodem, etc.), tu verras de quoi je veux parler. De plus, ceux qui donne leurs specs les donne au compte-goutte, et uniquement sur certains points du hard (par exemple, ATI et 3dfx restent muet sur le moyen de hard-décoder les mpeg2). Et encore, pas mal de hardware fonctionne uniquement parce que les chips sont relativement standard, pas parce que les constructeurs ont faits des drivers ou émis des specs.

        C'est quand meme ennervant de *systematiquement* galérer (ou attendre qu'un autre le fasse) pour pouvoir faire fonctionner du matos sous pretexte qu'on n'a pas Microsoft. Et vu l'état d'avancement actuel de Linux, le nombre de driver déjà existant malgré ca, etc., c'est bien la preuve d'une mauvaise volonté généralisée.
        • [^] # Re: Cool mais

          Posté par  . Évalué à 1.

          euh pour 3dfx ca va sans doute s'arranger car il appartient maintenant en majorite a nvidia, qui lui nous fait des beaux drivers...
          • [^] # Re: Cool mais

            Posté par  . Évalué à 1.

            > euh pour 3dfx ca va sans doute s'arranger car il
            > appartient maintenant en majorite a nvidia, qui
            > lui nous fait des beaux drivers...

            Rassure moi, c'est une blague ?

            Des beaux drivers bien propriétaires qui ont une facheuse tendance à planter sur toutes les TNT2 sur lesquelles je les ai essayés...
            • [^] # Re: Cool mais

              Posté par  . Évalué à 1.

              bah re-essaye .. parce que ce n'est pas le cas chez beaucoup de personnes ( dont moi )
              • [^] # Re: Cool mais

                Posté par  . Évalué à 0.

                Il restent néanmoins propriétaires ET fermés ces drivers, je les utilise et ça me fais bien ch...
                • [^] # Re: Cool mais

                  Posté par  . Évalué à 0.

                  C'est pour ça que j'ai acheté une Matrox G400. Les drivers sont opensource.

                  Peut-etre que les geforce vont plus vite, mais tant que les drivers ne seront pas opensource ils peuvent crever j'en veux pas.
            • [^] # Re: Cool mais

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

              tu l'as fais marcher comment ? chez moi, j'ai teste successivement les drivers 0.9x sur une tnt2 puis une geforce 2mx et ils ont jamais plante (ok, une fois a cause de l'overclock de mon celeron mais ca compte pas !) ...
        • [^] # Re: Cool mais

          Posté par  . Évalué à 1.

          tiens c'est nouveau les fonctions de harddecodage mpeg2 sur les 3dfx !!

          Tab
          • [^] # Re: Cool mais

            Posté par  . Évalué à 1.

            je parle bien sur de l'idct !

            Tab
      • [^] # Re: Cool mais

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

        Si tu me trouves les specs de l'agfa 1212p. je veux bien apprendre a programmer et faire un driver.
  • # Aie

    Posté par  . Évalué à 1.

    Le probleme majeur de ce livre, c'est que ca conserne le kernel 2.0
    Car du passage du 2.2 a 2.4, a vraiment plein de difference, sur les structures net_device,
    et surtout sur les locks.
    Mais bon je pense qu'il doit donner une base suffisante pour permettre de passer avec peu d'effort en 2.4.

    Tab
    • [^] # Re: Aie

      Posté par  . Évalué à 1.

      Je suis d'accord avec toi, l'intérêt c'est de pouvoir s'y attaquer, parce que sans point de départ, c'est pas évident de se dire :"Tiens aujourd'hui je vais m'écrire un pilote pour mon Winmodem.".
      Alors oui, les constructeurs ont du mal à donner leurs specs, mais quand ils le feront nous serons prêts ;)

      Ce genre de livres est fait pour débuter dans le domaine concerné, puis pour avoir de plus amples informations rien ne vaut un bon prof et des docs sur le Web. Donc, l'adaptation au 2.4 devrait sans faire sans trop de casse une fois lancé.
    • [^] # Re: Aie

      Posté par  . Évalué à 1.

      Et il y a tjrs la source ultime d'informations : /usr/src/linux/ !
      • [^] # Re: Aie

        Posté par  . Évalué à 1.

        c'est d'ailleurs les seules sources que j'ai trouve pour mon adapte mon driver de st201-fx
        en 2.4

        Tab
    • [^] # Re: Aie

      Posté par  . Évalué à 1.

      et la gestion memoire ...

Suivre le flux des commentaires

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