conseils pour l'ecriture de pilotes pour Linux

Posté par zyvad le 27 avril 2003 à 15:39. Modéré par Nÿco.

Étiquettes :

avr.

2003

Le néophyte ambitieux qui souhaite s'intéresser au noyau Linux est très souvent confronté à l'absence de documentation didactique : rares sont les livres qui ne sont pas obsolètes dès leur parution, du moins dans leurs détails.

Tariq Shureih vient d'annoncer sur la liste de messagerie de kerneljanitors.org son premier jet d'une série de conseils pour le developpement de pilotes de périphériques. Le document proposé par Tariq Shureih n'est certes qu'une première proposition ouverte à la critique, mais son évolution permettra certainement de se faire une idée une peu plus claire de ce qu'il convient de faire pour mettre les mains dans le cambouis.

Pratiquer pour apprendre reste en effet assez difficile malgré l'existence de http://www.kerneljanitors.org, qui propose de petits boulots consistant simplement en des recherches/remplacements dans le code, sans pour autant répondre à la critique fréquemment soulevée de l'algo à suivre pour faire router ses patches au bon endroit.

Parmi les premières remarques transmises sur la ML (et non archivées à ma connaissance), j'ai cru remarquer :

- Une mention de Rik van Riel selon laquelle il y aurait à pondérer les conclusions du chapitre concernant l'usage de goto dans le noyau
- Mention de l'utilité de fusionner ce document avec d'autres (dont notamment le discours Arjan van de Ven : "how NOT to write.." et celui de Greg Kroah-Hartman, "Documentation/CodingStyle and Beyond" des minutes du Ottawa Linux Symposium 2002) : lien 4).
- Mention de l'utilité de fusionner ce document avec les minutes du speech d'Alan Cox sur "Usefull kernel audits" (disponibles au format speex à partir du lien 2).

Aller plus loin

drivers DO & DON'T (6 clics)
Linux.conf.au minutes (speex) (3 clics)
Kernel Janitors (4 clics)
Ottawa LS proceedings 2002 (pdf) (3 clics)

# Re: conseils pour l'ecriture de pilotes pour Linux

Posté par hideo le 27 avril 2003 à 18:58. Évalué à 10.

on en profitera pour étudier :

--[ Secure Programming for Linux and Unix HOWTO ]
http://www.dwheeler.com/secure-programs/(...)

--[ Secure UNIX Programming FAQ ]
http://www.whitefang.com/sup/(...)

--[ Unix Programming Frequently Asked Questions ]
http://www.erlenstar.demon.co.uk/unix/faq_toc.html(...)

h_n
- [^] # Re: conseils pour l'ecriture de pilotes pour Linux
  
  Posté par lockness le 27 avril 2003 à 23:16. Évalué à 4.
  
  Et aller, hop, heureusement que la semaine prochaine y'aura le pont pour pouvoir lire toutes ces docs :o) !
- [^] # Re: conseils pour l'ecriture de pilotes pour Linux
  
  Posté par patatorz le 28 avril 2003 à 08:44. Évalué à 1.
  
  il y avait également un article dans Linux Magazine France (numéro 3x ou 4x) qui abordait le sujet et qui constituait une trés bonne introduction.
  L'article en question abordait la programmation du port PCI je crois.
  A vos archives !
  - [^] # Re: conseils pour l'ecriture de pilotes pour Linux
    
    Posté par AlphA le 28 avril 2003 à 09:34. Évalué à 5.
    
    Sans faire de pub (enfin si un peu :p) O'reilly a publié 2 excellents bouquins sur le noyau Linux. L'un portant sur le fonctionnement interne du noyau, malheureusement axé sur le 2.2 et un deuxième sur les pilotes de périphériques.
    
    Si la lecture des URL citées dans la news vous donnent envie d'aller plus loin, je vous conseille fortement le deuxième livre qui est une bible pour ce genre de travail. N.B. : attention, le nouveau format de module du futur 2.6 rendra surement une partie de ce livre obsolète (nouvelles macros, etc).
    
    Sinon, il est dispo sur le web sous license FDL mais j'ai plus l'url sous la main donc faut chercher un peu.
    
    Et sinon, y'a ça : http://www.linuxhq.com/lkprogram.html(...)
    Un point d'entrée pour de nombreuses docs.
    
    Notez bien que la programmation de pilote de périphérique ne requière pas d'être un guru du C. Il suffit de faire attention et de ne pas chercher à faire le porky sans être sur que ça ne finira pas en oops/kernel panic. Sinon, ça reste "assez" simple. Une bonne base de départ est tout simplement les autres drivers existants. On y trouvera les API à utiliser, les structures, etc.
    
    Petit conseil : l'utilisation d'un vmware (c'est pas mal) ou d'un UML (c'est mieux) est recommandé, histoire de pas crasher son poste de développement au cas où.
    
    --
    AlphA <qui a codé un driver de carte réseau wireless>
    - [^] # Re: conseils pour l'ecriture de pilotes pour Linux
      
      Posté par Christophe Lucas (site web personnel) le 28 avril 2003 à 09:56. Évalué à 4.
      
      Pour ceux qui veulent se faire une idée de :
      "Programmation de pilotes de périphériques" chez O'Reilly:
      http://www.xml.com/ldd/chapter/book/(...) (en anglais !!)
      
      --
      http://titux.tuxfamily.org(...)
      - [^] # Re: conseils pour l'ecriture de pilotes pour Linux
        
        Posté par Christophe Fergeau le 28 avril 2003 à 10:20. Évalué à 1.
        
        Y a aussi une série de docs dans les weekly news de lwn.net pour le portage de modules vers le 2.5
        
        [^] # Re: conseils pour l'ecriture de pilotes pour Linux
        
        Posté par Jérôme F. le 28 avril 2003 à 12:20. Évalué à 2.
        
        L'URL en est : http://lwn.net/Articles/driver-porting/ La liste d'article s'allonge de semaine en semaine, le dernier article étant dans la version payante de la semaine. <pub>N'oubliez pas de vous abonner, ça coûte pas granc chose, et ça permet de conserver une information relativement indépendante et surtout pertinente.</pub>
  - [^] # Re: conseils pour l'ecriture de pilotes pour Linux
    
    Posté par Philippe Bouamriou (site web personnel) le 28 avril 2003 à 20:40. Évalué à 1.
    
    Pour faire un peu de pub au Linux Journal, je fais remarquer que dans ce magazine US, ya une rubrique "Kernel Korner" que je trouve hyper cool.
    Dommage que l'on ne retrouve pas régulièrement une rubrique similaire dans le Linux Magazine France.

Suivre le flux des commentaires

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