À l'heure actuelle, la majorité des chaînes de développement suivent le modèle initié par les outils GNU au milieu des années 1980. Les principes sont les suivants.
Les outils de base comme le compilateur, l'éditeur de liens et le debugger, etc. sont des briques logicielles individuelles accessibles au niveau Shell. Ils disposent d'un grand nombre d'options ou de commandes permettant de répondre à pratiquement tous les besoins.
Ils partagent avec le système d'exploitation de nombreuses bibliothèques telles que la ou bibliothèque standard du Langage C courament appelée libc. Les fonctions ou les appels systèmes fournis par cette bibliothèque sont supportés depuis plus de 25 ans. Elles ont donc été largement adoptées sur un très grand nombre de systèmes différents.
Les interfaces de développement sont indépendantes des outils. Les environnements graphiques utilisateurs ne sont que des interfaces facilitant l'utilisation des jeux de commandes des outils GNU. Compte tenu du nombre et de la qualité de ces environnements, les développeurs se «composent» souvent une interface graphique à la carte.
Suivant le contexte de développement, les modes d'exploitation diffèrent. Généralement, on distingue les ordinateurs cibles avec système d'exploitation tels que les PCs et les ordinateurs cibles sans système d'exploitation comme les systèmes embarqués qui utilisent des microcontrôleurs spécialisés.
Ce contexte correspond aux enseignements «traditionnels» de programmation. L'utilisateur dispose d'une interface graphique (voir Section 13.1, « C/C++ sur Windows : Dev-Cpp ») pour éditer, compiler et exécuter les programmes (voir Section 4, « Cycle de développement »).
En règle générale, lorsque le programme est exécuté sur une machine cible avec système d'exploitation, les périphériques tels que le clavier, l'écran et la souris sont toujours disponibles.
Cette situation «confortable» suppose plusieurs couches intermédiaires de logiciel entre l'utilisateur et le matériel. L'ensemble de ces couches intermédiaires s'appelle un système d'exploitation. L'image ci-dessous représente les couches constituant un système d'exploitation.
Ce logiciel ne fait pas vraiment partie du système d'exploitation. À la mise sous tension de l'équipement (PC ou autre), son rôle est de recenser les ressources matérielles disponibles : type de processeur, quantité de mémoire, nombre et type de périphériques de stockage, interfaces réseau, écran, clavier, etc. Une fois l'étape de recensement passée, les périphériques de stockage sont scrutés un à un à la recherche d'un code particulier qui permet le lancement du système d'exploitation.
Ce logiciel constitue le coeur du système d'exploitation. Il assure 3 fonctions principales :
Le noyau intègre ses propres fonctions de recensement des ressources matérielles. Il peut très bien ne tenir aucun compte des informations fournies par le BIOS. Le noyau doit posséder un pilote pour chaque périphérique d'entrée-sortie «présent» dans le système.
Un noyau moderne doit aussi gérer l'ajout et le retrait de périphériques en cours de fonctionnement. On parle de branchement «à chaud» ou hotplug.
Un système peut intégrer différents types de mémoires dynamiques et le noyau doit gérer ces différents éléments comme un tout cohérent. Les programmes doivent accéder à ce «plan mémoire» de façon transparente en utilisant des segments alloués en fonction de leurs besoins.
De plus, si le plan mémoire est partagé entre plusieurs programmes, le noyau doit utiliser un algorithme spécifique de planification et de distribution des accès entre ces programmes. On parle alors de système multi-tâches. Linux est un exemple caractéristique de ce type de noyau.
Le temps du processeur doit être partagé entre les programmes comme le plan mémoire. On découpe donc ce temps processeur en tranches qui sont attribuées aux programmes à la demande.
La fonction correspondante du noyau est appelée ordonnanceur ou scheduler. Sur un système moderne dans lequel les temps d'accès aux périphériques et les transmissions réseau sont suffisamment rapides, c'est l'ordonnanceur qui est le «maître» du temps. On peut le comparer à une horloge de réglage du rythme cardiaque d'un système.
Un Shell permet à l'utilisateur du système de lancer des programmes ou commandes. On parle de commande lorsqu'il s'agit de «manipuler» le système : lister les fichiers d'un répertoire, afficher la quantité de mémoire disponible, etc.
Sur les systèmes multi-tâches et multi-utilisateurs tels que GNU/Linux et *BSD, de nombreux Shells peuvent être actifs en même temps. À l'inverse, sur les systèmes mono-tâches hérités du DOS (Disk Operating System) de Micro$oft™, on ne dispose que d'un Shell unique.
Lorsque plusieurs programmes doivent être exécutés sur un même système, il est fréquent que ces programmes échangent des paramètres où se lancent en fonction d'actions réalisées par d'autres programmes. Lorsque l'on utilise une interface graphique et que l'on clique sur une fenêtre pour l'activer, on réalise une opération de ce type.
À ce niveau on trouve généralement l'interface graphique utilisateur qui permet de réaliser les manipulations système de façon plus intuitives qu'au niveau Shell. À ce gestionnaire de fenêtres sont associées toutes les applications usuelles d'un système généraliste : navigation Web, traitement de textes, Environnement de développement intégré (comme Section 13.1, « C/C++ sur Windows : Dev-Cpp »), etc.
C'est aussi à ce niveau que les programmes développés par nos soins sont exécutés.
Ce contexte correspond aux enseignements pratiques d'informatique industrielle. Si l'utilisateur dispose d'une interface graphique de développement intégrée, le logiciel développé doit être exécuté sur un système spécialisé. On parle de système embarqué dédié à la réalisation de fonctions spécifiques. Il est rare que ces systèmes disposent d'un écran et d'un clavier.
Contrairement à la situation précédente avec système d'exploitation, les conditions de développement sont moins «confortables». Ceci-dit, comme le nombre de couches logicielles est nettement réduit, la description est plus simple.
Le seul point commun entre le moniteur et le BIOS se situe au niveau du lancement de programme. Là où le BIOS identifie le code de lancement du système sur le premier secteur d'un périphérique, le moniteur identifie l'adresse de lancement d'une application dans le plan mémoire du microcontrôleur.
Sur un système spécialisé avec microcontrôleur, la configuration matérielle est figée. Il est donc totalement inutile de procéder à un recensement des ressources du système.
Le premier rôle d'un moniteur est d'assurer le téléchargement des programmes entre le système de développement (généralement un PC) et le système spécialisé (le microcontrôleur). Ce téléchargement est réalisé à l'aide une liaison série ou réseau.
Les microcontrôleurs récents intègrent en plus du moniteur un ensemble de sous-programmes (routines) qui offrent des fonctions simples de pilotage de périphériques et de manipulations de la mémoire intégrée au composant.
À ce niveau le microcontrôleur exécute le ou les programme(s) utilisateur. Comme on n'utilise pas de noyau, les programmes utilisateur doivent intégrer directement le pilotage des périphériques : liaison série, affichage LCD, conversion analogique/numérique, capteurs, etc.
![[Linux France logo]](./../images/lf-petit.png)
Vous êtes ici : 
