• # Ca dépend d'ou tu pars

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

    Une première étape est d'avoir un bon niveau en C.

    Ensuite tu peux apprendre plus de choses sur le kernel en écrivant un petit driver (je te consille de lire http://lwn.net/Kernel/LDD3/ ) ou en corrigeant ceux en staging.

    Je pense que débuguer un problème sur une machine que tu as, ou ajouter le support d'un matériel que tu as sont des bonnes manières d'apprendre.

    Et sinon, pourquoi tu veux devenir un kernel hacker ?

    • [^] # Re: Ca dépend d'ou tu pars

      Posté par  . Évalué à 3.

      J'aime bien l'idée de maîtriser les arcanes de l'ordinateur, auxquelles peu de gens pensent réellement lorsqu'ils en utilisent un. En quelque sorte, le kernel, c'est les fondamentaux de la programmation, c'est à dire programmer pour pouvoir utiliser son ordinateur. J'aime bien l'idée d'aller voir ce qu'il y a réellement dans la machine, et de comprendre réellement comment fonctionne l'ordinateur que j'utilise.

      Le second point est que j'aime bien l'univers technique que cela représente, et l'idée d'une communauté de développement aussi large que celle de linux, et aussi accueillante. Les news cryptiques de patrick_g y sont aussi certainement pour quelque chose :) !

      Une autre raison que j'ai trouvé, est que malheureusement, c'est très dur d'être polyvalent en informatique. Se spécialiser dans la programmation de noyau me semble donc intéressant comme premier choix, n'ayant pas tellement de motivation pour les problématiques du développement web ou des interfaces graphiques.

      Systemd, the bright side of linux, toward a better user experience and on the road to massive adoption of linux for the desktop.

      • [^] # Re: Ca dépend d'ou tu pars

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

        Se spécialiser dans la programmation de noyau me semble donc intéressant comme premier choix, n'ayant pas tellement de motivation pour les problématiques du développement web ou des interfaces graphiques.

        Attention quand même: le marché du travail pour le développement noyau est beaucoup plus restreint que celui des interfaces graphiques ou web...

        • [^] # Re: Ca dépend d'ou tu pars

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

          Oui il y a peu de jobs mais encore moins de gens à embaucher donc c'est pas vraiment un problème.
          Je suis contacté toutes les semaines depuis que mon profil LinkedIn contient le mot kernel...

        • [^] # Re: Ca dépend d'ou tu pars

          Posté par  . Évalué à 3.

          C'est vrai mais les compétences kernel sont très rares, et manquent à quasi-tous les programmeurs, ils sont si loin de la machine que leur code est stupidement exploité.

          Résultat ça rame sur un serveur 4 processeur gavé de ram.... au mieux voir, ca va planter.

          Parce que les programmeurs ont un défaut commun, c'est d'apprendre le tout graphique sans avoir avant appris à coder système et encore moins noyau.

          Ils sont pas mauvais pour autant, ils font ce qui semble le mieux, mais il manque la culture informatique "bas niveau" certains même n'ont pas fait d'électronique au lycée, donc pas d'assembleur pour comprendre réellement les limites et correspondances temps/cycle/instruction/courant électrique.

          Un programmeur système qui basculera vers des couches graphiques après, sera automatiquement bon, (sauf à la limite sur le design de ses interfaces), alors que l'inverse n'est vrai qu'au prix de gros efforts, voir d'une formation réelle.

    • [^] # Re: Ca dépend d'ou tu pars

      Posté par  . Évalué à 6.

      Une première étape est d'avoir un bon niveau en C.

      En C et en Anglais je dirais.

    • [^] # Re: Ca dépend d'ou tu pars

      Posté par  . Évalué à 1.

      Je conseille aussi l'écriture d'un petit driver, c'est ce qui est souvent recommandé. Il y a le livre sur l'écriture des drivers qui explique bien comment commencer, également (Linux Device Drivers ). La lecture de la doc est aussi indispensable, d'ailleurs il y a des documentations pour commencer à hacker, qui explique les erreurs à ne pas faire, le coding style, ...

      Perso j'essaye aussi de m'y mettre depuis un certain temps. J'ai écrit deux petits drivers pour tester en partant de drivers existants (un driver pour écran tactile, un pour un clavier). Les deux fois, quelqu'un avait intégré entre temps un driver qui faisait la même chose, mais en mieux : ça s'intégrait mieux avec les autres drivers, il n'y avait pas de code redondant, etc.

      Maintenant j'essaye de me mettre sur le driver libre poulsbo vu que j'ai cette carte graphique sur mon netbook. Je vais par exemple essayer de faire marcher le suspend qui plante, mais là dessus j'ai un peu du mal à déboguer.

    • [^] # Re: Ca dépend d'ou tu pars

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

      Je te conseillerai de commencer par récupérer les sources du noyaux (non ? qui l'eu crû ?!), et de regarder le code pour t'y familiariser avant de véritablement y toucher.
      Après au choix, tu peux commencer par faire ton propre module, ou tenter de modifier du code existant pour voir ce qu'il se passe.

  • # LKML

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

    Tu peux aller t'inscrire sur la LKML et lire tous les messages pendant une semaine.

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

  • # Écriture d'un pilote

    Posté par  . Évalué à 2.

    Tu as les deux journaux de Pinaraf sur l'écriture d'un pilote et son intégration dans le noyau.
    http://linuxfr.org/users/pied/journaux/de-l%C3%A9criture-dun-pilote-linux-pour-un-gadget
    http://linuxfr.org/users/pied/journaux/de-l%C3%A9criture-dun-pilote-linux-pour-un-gadget-suite

  • # Visionner et Re-visionner Greg Kroah-Harthman...

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

    ... Write and Submit your first Linux Kernel patch, c'est très instructif

    http://www.youtube.com/watch?v=LLBrBBImJt4

Suivre le flux des commentaires

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