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
Quel degré ou compétences en C pour comprendre le code source de Linux?
Bonjour tout le monde,
D'abord GRAND merci à tout les responsables de ce forum.
Comme mon pseudo l'indique bien, je suis un débutant en C mais avec un peu d’expérience en assembleur (8086, AVR, PIC).
Mon objectif et d'étudier certaines parties du code source pour linux ( MM, Scheduling et IPC).
Donc:
1- Quel degré de maitrise du C est nécessaire pour cette tache?
2- Quelles ressources pour m'aider à progresser rapidement?
3- Des conseils?
Merci beaucoup par avance.
Le C est un langage plutôt simple. Il faut bien le connaître mais cela peut aller assez vite.
Le code source de Linux est compliqué surtout parce que la composante métier est compliquée.
Cela aide déjà beaucoup d'avoir des connaissances en assembleur, parce que ça garantit que tu as aussi des connaissances sur les ordinateurs eux-mêmes, ce qui est rigoureusement indispensable pour comprendre un OS.
Après, les parties de l'OS que tu évoques sont parmi les plus compliquées. Elles reposent sur: 1) une vision générale du système d'exploitation (la répartition en différentes couches, la gestion de la mémoire, etc.), 2) des algorithmes pas évidents et 3) des connaissances métiers précises. Je ne pense pas qu'il soit possible de les acquérir en lisant le code source.
Pour les ressources disponibles sur le site, tu devrais regarder à cet endroit et choisir selon ta maîtrise de l'anglais et tes impressions: http://linux.developpez.com/cours/?p...#Programmation
Il existe aussi un micro noyau, qui accomplit des taches similaires à Linux: Minix. A la fac, c'est là-dessus qu'on avait étudié le fonctionnement d'un OS.
Ca peut peut-être te servir d'introduction dans le domaine.
Merci stendhal666 et leternel de vos réponses c'est très gentil à vous.
En effet, les sources d'un SE comme Linux c'est pas de la tarte, surtout la gestion de la mémoire, l'ordonnancement des processus et leurs inter-communications.
C'est pour ça que je me suis venu vers vous solliciter votre aide.
- Quelles sont les connaissances métiers qu'il faut acquérir?
- Quels sont les concepts particuliers utilisés dans la programmation d'un SE et comment les implémenter en C?
Je reformule la question dans l’autre sens : quels sont les éléments du C nécessaires pour la programmation d'un SE?
- A part le livre d'ANDREW S. TANENBAUM sur MINIX, est-ce qu'il y a d'autres notes (en français surtout) exliquant cet SE?
Pour le moment j'essaye de comprendre le fonctionnement général d'un SE.
- OPERATING SYSTEM CONCEPTS d'ABRAHAM SILBERSCHATZ
- OPERATING SYSTEMS: Design and Implementation d'ANDREW S. TANENBAUM
J'ai déjà envisagé de faire de MINIX et XINU mon exercice d'échauffement avant d’attaquer linux!!
J'avoue je me sens un peu embrouillé par la complexité de la tache, j'essaye d'organiser un plan de travail efficace. Je me suis dit il faut d'abord avoir un bon niveau en C.
Je suis toujours à l'écoutes de vos conseils.
Merci encore
Le C est un détail ; je prends la liberté de citer stendhal666 :Tu as déjà des bases d'algorithmique impérative ? Tu connais les structures de contrôle de base : si/sinon, tant que, fonctions..? Si oui alors avec ton bagage assembleur tu n'auras aucun problème avec le C. Ce sont les concepts et les connaissances des détails et contraintes techniques qui sont difficiles à appréhender dans ton projet, pas le langage (bon, c'est vrai dans le cas du C mais je n'aurais pas pensé la même chose si ces OS étaient écrits en Rust...Envoyé par stendhal666
).
Un jour un vieux barbu m'a dit :
Du coup et par curiosité, j'ai téléchargé le noyau 4.4.3 ici https://www.kernel.org/ et j'ai constaté 2 choses :Sache, petit con, que seuls ceux qui connaissent déjà le kernel peuvent apprendre comment fonctionne le kernel
La première, est qu'on ne comprend strictement rien à l'arborescence. La seconde, est que le vieux barbu avait raison !
Je pense que le kernel a prit tellement d'ampleur qu'il est maintenant très difficile de prendre le train en marche mais tes questions m'intéressent aussi. Je me suis toujours demander comment certain faisait pour porter le kernel sur des microcontrôleurs ou encore faire des drivers car ceci implique de savoir comment le noyau fonctionne. Je crois aussi qu'il te faut des connaissances en électronique car qui dit noyau dit forcément très bas niveau, registres etc...
Pourquoi ne t'es tu pas intéressé à des noyaux plus petits comme FreeRTOS par exemple, puisque tu connais des microcontrôleurs de chez Atmel et Microchip ?
- Pour répondre à Matt_Houston:
Oui bien sûr, j'ai déjà une certaine base. Qui ne connait pas les if-then-else ou le do-while?!
J'ai encore un peu de difficulté concernant l'utilisation des pointeurs, structures, énumérations...
- Coté électronique je pense que je suis très bon. J'ai déjà réalisé une carte à base du 6802 et une autre à base du 8088 en plus de beaucoup de projets avec microcontrôleurs AVR et PIC.
Seulement j'ai tjrs programmé en assembleur, très peu de C hélas.
- Vincent PETIT:
Oui effectivement le noyau linux c'est + de 10 millions de ligne de code je pense !!!!
J'ai oublié de dire que ma cible est surtout le noyau 0.01. Il n'ya qu'une seule architecture (x86) et l'arborescence des sources est relativement facile à appréhender.
- Les SE temps réel genre FreeRTOS c'est une autre histoire que je réserve pour plus tard.
j'ai trouvé un exemple d'une application multitâche pour AVR (ATMEGA32) j'ai retouché le code pour qu'il marche sur un ATTINY2313 (moins de RAM) et ça marche "like a charm" !
http://blog.vinu.co.in/2012/03/multi...-atmega32.html
ça m'a beaucoup aidé à comprendre déjà qqs notions:
- preemptive multitasking.
- Context saving (backup).
- Context switching.
- Timer interrupt driven scheduler (type round robin).
Bonjour et bienvenue.
Il faut être habitué. Pas besoin d'être un expert, ni de connaître la norme par cœur, cela dit. Tout ce qui est piège syntaxique ou spécificités avancées du langage C est en général évité dans un projet collaboratif comme le noyau. Par contre, il faut être à l'aise avec tout ce qui peut être réellement utile, comme les pointeurs de fonctions. En outre, le noyau Linux en particulier s'appuie parfois sur certaines extensions de GCC avec lequel il est compilé le plus souvent, même si on essaie de s'en affranchir.D'abord GRAND merci à tout les responsables de ce forum.
Comme mon pseudo l'indique bien, je suis un débutant en C mais avec un peu d’expérience en assembleur (8086, AVR, PIC).
Mon objectif et d'étudier certaines parties du code source pour linux ( MM, Scheduling et IPC).
Donc:
1- Quel degré de maitrise du C est nécessaire pour cette tache?
En outre, UNIX et C sont intimement liés dans l'histoire parce qu'ils ont été conçus par les mêmes personnes. Les gens qui continuent aujourd'hui à développer des unixoïdes viennent en général des mêmes courants et sont souvent des programmeurs C aguerris.
Si tu veux connaître le noyau Linux en particulier et te plonger directement dans le bain, tu peux visiter Kernel Newbies. C'est un site destinés aux programmeurs déjà avertis et qui veulent se former doucement à la programmation noyau en vue de contribuer à (plus ou moins long) terme.2- Quelles ressources pour m'aider à progresser rapidement?
Tu peux aussi consulter Linux Device Drivers qui concerne la rédaction de pilotes de périphériques en particulier (donc a priori pas directement tes centres d'intérêts).
Enfin, je pense que tu serais très intéressé par le défi Eudyptula, mais comme il y a des personnes physiques derrière ce défi et qu'elles traitent directement les soumissions des concurrents, les délais peuvent être très longs (entre une semaine et un mois d'une tâche à l'autre), même s'il paraît que la mise en place de certains scripts a beaucoup arrangé les choses.
J'en ai deux :3- Des conseils?
Merci beaucoup par avance.
- Commence d'abord par apprendre la programmation système UNIX en elle-même du côté utilisateur, si tu n'es pas encore au point. Si c'est cela que tu veux connaître en fait, alors se plonger dans le noyau n'est pas la meilleure manière de le faire. Non seulement le noyau en lui-même est assez compliqué, mais il est aussi garant d'un certain nombre de tâches de maintenance, qui se répètent tout au long du code et qui sont parfois assez ennuyeuses.
Par exemple, le noyau n'écrit ou ne lit jamais directement en espace utilisateur : chaque fois qu'il doit le faire, il appelle une fonction qui recopie la portion de mémoire concernée en espace noyau. Et il ne faut jamais oublier de le faire. Cela est dû a un certain nombre de contraintes liées par exemple aux accès concurrents en milieu multithreadé ou carrément sur des machines massivement parallèles, mais également au fait que les pages en question ne sont pas forcément accessibles. Elles peuvent être dans le swap. C'est le rôle de la mémoire paginée de gérer tout cela en espace utilisateur de façon transparente pour celui-ci, en appelant justement les bons appels noyau. Il faut bien qu'à un moment où un autre, le travail se fasse et là, on est justement dans le vif du sujet.
- Ne cours pas plusieurs lièvres à la fois : familiarise-toi avec le C. Si tu as l'expérience de l'assembleur, tu devrais atteindre un niveau correct en trois semaines à un mois. Familiarise-toi ensuite avec la programmation système vue de l'extérieur avec quelques programmes simples et, une fois qu'ils seront au point, demande-toi ce qu'ils nécessitent au préalable pour fonctionner et comment, toi, tu aurais implémenté ces infrastructures. Cela t'aidera beaucoup à comprendre les choix qui ont été faits tout au long du développement.
Difficile à dire précisément parce que cela change tellement vite que même les livres consacrés à Linux et écrits par ses principaux protagonistes deviennent obsolètes avant qu'on ait vraiment eu le temps de les assimiler entièrement. Le plus instructif est de lire les dépêches consacrées aux mises à jour majeures du noyau. Fais une recherche avec « noyau 4.4 », par exemple, parce qu'il est sorti très récemment. On y trouve à chaque fois beaucoup d'améliorations techniques pointues portées à des concepts en place de longue date, par exemple une lecture plus continue et moins basée sur les IRQ des disques lorsqu'il s'agit de SSD.
Donc, des choses comme l'ordonnancement des processus peuvent grandement changer d'un noyau à l'autre sans que l'utilisateur en ait conscience.
Par contre, la plupart de ces choses sont purement algorithmiques et ne sont donc pas forcément liées à un langage. Certes, on arrive au point où il faut gérer les ressources proprement dites de ta machine, mais si tu as une idée globale de la façon dont tu t'y prendrais en assembleur, alors tu sauras le faire en C.
Ça dépend de ce que tu appelles arborescence (dans laquelle un grand ménage avait pourtant été effectué il y a quelques temps). L'arborescence des fichiers a quand même une certaine cohérence et celle du menu de configuration aussi, même si elle peut faire peur de prime abord. En réalité : l'arborescence présentée par « make xconfig » ou « make gconfig » est directement issue de celle qui s'affichait en Tcl/Tk jusqu'aux noyaux 2.4 : http://networking.ringofsaturn.com/Unix/xconfig.jpgDu coup et par curiosité, j'ai téléchargé le noyau 4.4.3 ici https://www.kernel.org/ et j'ai constaté 2 choses :
La première, est qu'on ne comprend strictement rien à l'arborescence. La seconde, est que le vieux barbu avait raison !
Sur cette image, chaque bouton ouvrait un panneau qui contenait des cases à cocher et/ou boutons radios servant à configurer chaque option. On a commencé à avoir des sous-panneaux dans certaines rubriques et, quand il est apparu des sous-sous-panneaux, l'équipe de développement a migré vers une arborescence plus traditionnelle.
Toujours est-il que les grands titres de chacun de ces boutons sont relativement explicites et que le premier niveau de l'arborescence actuelle est toujours organisé plus ou moins de la même façon (avec Processor Type And Features et General Setup en tête de liste, puis les périphériques caractère et bloc, et Kernel Hacking à la fin).
Pas en électronique à proprement parler (à part peut-être quelques notions élémentaires d'électronique numérique).Je pense que le kernel a prit tellement d'ampleur qu'il est maintenant très difficile de prendre le train en marche mais tes questions m'intéressent aussi. Je me suis toujours demander comment certain faisait pour porter le kernel sur des microcontrôleurs ou encore faire des drivers car ceci implique de savoir comment le noyau fonctionne. Je crois aussi qu'il te faut des connaissances en électronique car qui dit noyau dit forcément très bas niveau, registres etc...
Par contre, ça implique effectivement une très bonne connaissance du noyau, mais pas forcément exhaustive non plus. En fait, ce qu'il faut, c'est surtout que la plateforme cible offre un « minimum syndical » au niveau matériel, soit au moins un timer à la disposition du système capable de déclencher des IRQ à intervalles fixes et probablement, aujourd'hui, un système de mémoire virtuelle permettant de remapper un segment (et encore, je ne suis même pas sûr que ce soit obligatoire à cent pour cent). Il y a bien quelques bootstraps en assembleur propre à chaque architecture cible mais très vite, on embraye vers le C censé être portable.
Le reste est soit complètement algorithmique, soit basé sur un systèmes de pilotes qui n'entrent en jeu que quand le périphérique est détecté. Et là encore, ces périphériques sont censés être intimement liés à l'architecture de la machine mais généralement, ils le sont par l'intermédiaire d'un bus standard de l'industrie, comme le PCI, si bien que c'est surtout lui que l'on gère et que cela devient transparent pour le pilote.
MERCI Obsidian pour ta réponse très pertinente.
Justement, je veux pas courir plusieurs lièvres à la fois. Comme j'ai dit au début, mon plan de travail consiste à bien maitriser le C d'abord.
- Est-ce qu'il y a des bons tutos sur les pointeurs de fonctions, le passage des pointeurs en arguments et l'utilisation des structures?
- Si vous pouvez m'aider à faire un plan d'étude de C efficace je serai très reconnaissant, en plus ça aidera certainement aussi bcp d'autres débutants.
En ce qui concerne la programmation système, comment aide t'elle à comprendre le fonctionnement du noyau si le but même du SE est de faire abstraction des détails de bas niveau?
Enfin, je pense pas que je suis à la hauteur du "The Eudyptula Challenge" ou de l'écriture des "devices drivers" par contre le site "Linux Kernel Newbies" est une mine d'informations.
Hello,
Siguillaume vient justement de résumer et rafraîchir tout ce qui est disponible ou référencé chez nous à ce sujet :
http://www.developpez.net/forums/d15...mer-langage-c/
Tout le monde conseille le livre de Kernigan & Ritchie (auteurs du langage C).
Tu peux aussi essayer le cours de C. Casteyde, assez clair et pas trop long, du chapitre 1 à 7. J'en étais moi-même assez fan en son temps. Il a la particularité de mélanger le C et le C++, mais en faisant clairement le distingo à chaque fois, et en indiquant clairement ce qui est propre à l'un ou l'autre ou commun aux deux langages. C'est utile car il y a beaucoup de choses qui ont été introduites avec le C++ puis reprises dans C99 a posteriori, comme les fonctions inline dans une certaine mesure et les commentaires « // ».
Pour les pointeurs de fonction, il n'y a rien de compliqué en soi, mais leur syntaxe effraie souvent les débutants et on les comprend, même si une fois que l'on a saisi le principe, cela devient aussi élémentaire que le reste. Un pointeur de fonction contient simplement l'adresse du point d'entrée d'une fonction, ce qui permet de l'appeler. Invoquer le nom d'une fonction sans le faire suivre des paramètres entre parenthèses se résout en une expression qui donne justement cette adresse. Réciproquement, ajouter des parenthèses contenant des paramètres à un pointeur de fonction permet d'invoquer la fonction pointée. C'est utile pour réaliser des callbacks, des tableaux de fonctions pouvant être indexés (pour choisir une procédure en fonction d'un critère), des chargements dynamiques de bibliothèques pendant l'exécution avec dlopen(), mais également de la programmation fonctionnelle dans une certaine mesure.
Parce que le noyau SERT à faire de la programmation système. Il sert à mettre en place les infrastructures nécessaires pour faire tourner un programme dans un environnement sécurisé, sur lequel on peut ensuite bâtir tout le reste, notamment bibliothèques de fonctions et dæmons de services, lesquels ne sont rien d'autres que des applications ordinaires fonctionnant en arrière-plan et chargées d'assurer certaines tâches pour le compte des autres applications.- Si vous pouvez m'aider à faire un plan d'étude de C efficace je serai très reconnaissant, en plus ça aidera certainement aussi bcp d'autres débutants.
En ce qui concerne la programmation système, comment aide t'elle à comprendre le fonctionnement du noyau si le but même du SE est de faire abstraction des détails de bas niveau?
Un « processus », par exemple, est un concept répandu en informatique mais ce n'est pas une entité fondamentale : le micro-processeur n'en a aucune notion. C'est simplement une manière d'organiser les tâches à exécuter en y associant un contexte propre (formellement : état des registres du processeur, liste des segments mémoire allouées et des différentes ressources système, comme les fichiers ouverts), de façon à ce que l'on puisse temporairement passer à autre chose et y revenir facilement ensuite.
À partir du moment où tu es au clair avec ces concepts (et que tu as l'habitude de les utiliser en temps normal), tu peux commencer à te demander ce qu'il faudrait écrire pour les implémenter depuis zéro. Et c'est exactement ce que tu vas retrouver dans les sources du noyau.
Pour Eudyptula, la première tâche est triviale et accessible à presque tout le monde. La dernière est difficile car c'est un cas d'étude relativement court mais qui pourrait être tout-à-fait être demandé en situation réelle. Ce n'est donc pas un cas d'école, par contre c'est tout-à-fait accessible à un programmeur C en entreprise, même junior.Enfin, je pense pas que je suis à la hauteur du "The Eudyptula Challenge" ou de l'écriture des "devices drivers" par contre le site "Linux Kernel Newbies" est une mine d'informations.
Pour les pilotes de périphériques, tu n'es peut-être pas obligé d'aller si loin (surtout au départ), par contre tu peux tout-à-fait essayer d'écrire et compiler un « module » du noyau, même si celui-ci se contente d'écrire « Hello World » dans dmesg. C'est même un exercice relativement répandu. Lis le LKMPG (Linux Kernel Module Programming Guide) même s'il n'est plus tout-à-fait jeune (il va jusqu'aux noyaux 2.6).
Merci encore Obsidian pour les bons conseils.
J'ai trouvé dans le livre de TANENBAUM (Operating Systems Design and Implementation) annexe A un bon résumé de C, justement écrit pour le but d'aider à comprendre les sources de MINIX.
C'est super!
Répondre avec citation
Partager