Quelle est la différence entre uclinux et Linux

Différences : 1. Uclinux utilise la gestion de la mémoire par pagination, tandis que Linux utilise la gestion de la mémoire virtuelle ; 2. Uclinux n'a pas d'appel système fork et utilise vfork, tandis que Linux utilise un appel système fork ; 3. Uclinux ne peut pas ajouter de pile de processus ; lors de l'exécution, tandis que Linux peut augmenter la pile de processus au moment de l'exécution.

L'environnement d'exploitation de ce tutoriel : système linux7.3, ordinateur Dell G3.

Quelle est la différence entre uclinux et linux

Dans le mot anglais uClinux, u signifie Micro, ce qui signifie petit, et C signifie Control, ce qui signifie contrôle

Donc uClinux est Micro-Control-Linux, qui signifie littéralement ". Un système Linux conçu pour le domaine du microcontrôle".

La différence entre ucLinux et Linux

• Pas de gestion de la mémoire virtuelle

• Impossible d'augmenter la pile de processus pendant l'exécution

• Ne prend pas en charge la pagination

• Le programme exécutable n'est pas elfe, mais plat

• Vous ne pouvez pas utiliser fork, mais utilisez vfork

• RAMDISK

uClinux est un système d'exploitation Linux embarqué pour le champ de contrôle. Il est dérivé du noyau Linux 2.0/2.4 et hérite de la plupart des fonctionnalités de. Linux grand public.

Convient aux microprocesseurs/microcontrôleurs qui n'ont pas d'unité de gestion de mémoire (MMU). Le manque de prise en charge de MMU constitue la différence fondamentale entre uClinux et Linux traditionnel.

Pour uCLinux, sa conception est destinée aux processeurs sans MMU et ne peut pas utiliser la technologie de gestion de la mémoire virtuelle du processeur. uCLinux utilise toujours la gestion de la pagination de la mémoire et le système pagine la mémoire réelle au démarrage. Le programme se charge par pages pendant le chargement de l'application. Cependant, comme il n’y a pas de gestion MMU, uCLinux adopte en réalité une véritable stratégie de gestion mémoire.

Le système uCLinux a un accès direct à la mémoire et les adresses accessibles dans tous les programmes sont de véritables adresses physiques. Le système d'exploitation ne protège pas l'espace mémoire et chaque processus partage en fait un espace d'exécution. Avant qu'un processus ne soit exécuté, le système doit allouer suffisamment d'espace d'adressage continu pour le processus, puis le charger dans l'espace continu de la mémoire principale.

Les opérations sans protection de la mémoire(Memory Protection) conduiront aux résultats suivants :

Même si un pointeur invalide est appelé par un processus non privilégié, une erreur d'adresse sera déclenchée et potentiellement provoquer le crash du programme ou même provoquer le système à planter ou à se bloquer. De toute évidence, le code exécuté sur un tel système doit être soigneusement programmé et minutieusement testé pour garantir sa robustesse et sa sécurité.

Pour Linux ordinaire, différents programmes utilisateur doivent être exécutés. Sans protection de la mémoire, la sécurité et la fiabilité du système seront cependant considérablement réduites pour les systèmes uClinux intégrés, car les programmes en cours d'exécution sont souvent expédiés de l'usine ; L'application a été solidifiée auparavant, il n'y a pas de risque caché d'intrusion de programmes mettant en danger la sécurité du système. Par conséquent, tant que l'application a subi des tests relativement complets, la probabilité de problèmes peut être contrôlée dans une plage limitée.

L'absence de mémoire virtuelle(Virtual Memory) entraîne principalement les conséquences suivantes :

Tout d'abord, les processus chargés par le noyau doivent pouvoir s'exécuter de manière indépendante, quel que soit leur emplacement en mémoire. La première façon d'atteindre cet objectif est de « corriger » l'adresse de base du programme une fois qu'il est chargé dans la RAM ; une autre façon consiste à générer du code qui utilise uniquement l'adressage relatif (appelé « code indépendant de la position », Position Independent Code, appelé « code indépendant de la position »). comme PIC). uClinux prend en charge les deux modes.

Deuxièmement, nous devons résoudre le problème de l'allocation et de la libération de mémoire dans le modèle de mémoire plate. Une allocation de mémoire très dynamique peut provoquer une fragmentation de la mémoire et épuiser les ressources du système. Pour les applications qui utilisent l'allocation dynamique de mémoire, une façon d'augmenter la robustesse consiste à remplacer les appels malloc() par un pool de mémoire tampon pré-alloué.

Étant donné que la mémoire virtuelle n'est pas utilisée dans uclinux, l'échange de pages dans et hors de la mémoire n'est pas implémenté car il n'y a aucune garantie que la page sera chargée au même emplacement dans la RAM. Sur les ordinateurs ordinaires, le système d'exploitation permet aux applications d'utiliser un espace mémoire plus grand que la mémoire physique (RAM), ce qui est souvent obtenu en configurant une partition d'échange sur le disque dur. Cependant, dans les systèmes embarqués, la mémoire FLASH est généralement utilisée à la place du disque dur, et il est difficile de mettre en œuvre efficacement l'accès à l'échange de pages mémoire. Par conséquent, l'espace alloué aux applications en cours d'exécution n'est pas limité à une taille supérieure à l'espace RAM du système.

Le multitâche n'est pas affecté. Quels anciens démons de réseau (démons) utilisent largement fork() doivent être modifiés. Étant donné que le processus enfant s'exécute dans le même espace d'adressage que le processus parent, il est également nécessaire, dans certains cas, de modifier le comportement des deux processus.

De nombreux programmes modernes s'appuient sur des processus enfants pour effectuer des tâches de base, permettant au système de rester dans un état « interactif » même lorsque le processus est fortement chargé. Ces programmes peuvent nécessiter des modifications substantielles pour accomplir la même tâche sous uClinux. Si une application critique reposait fortement sur une telle structure, elle devrait être réécrite.

Supposons qu'il existe un simple démon réseau qui utilise largement fork(). Ce démon écoute sur un port (ou socket) connu et attend que les clients du réseau se connectent. Lorsque le client se connecte, le démon lui donne de nouvelles informations de connexion (nouveau numéro de socket) et appelle fork(). Le processus enfant se connectera alors au client sur le nouveau socket, et le processus parent sera libéré et pourra continuer à écouter de nouvelles connexions.

uClinux n'a ni une pile à croissance automatique ni une fonction brk(), donc les programmes de l'espace utilisateur doivent utiliser la commande mmap() pour allouer de la mémoire. Pour plus de commodité, malloc() implémenté dans la bibliothèque de langage C d'uclinux est essentiellement un mmap(). Au moment de la compilation, vous pouvez spécifier la taille de la pile de votre programme.

Enfin, le processeur de la carte cible uClinux ne dispose pas d'une unité matérielle de gestion de la mémoire, ce qui nécessite quelques modifications de l'interface du système Linux. La plus grande différence est probablement qu’il n’y a pas d’appels système fork() et brk(). L’appel de fork() copiera le processus et créera un processus enfant. Sous Linux, fork() est implémenté à l'aide de pages de copie sur écriture. Puisqu'il n'y a pas de MMU, Uclinux ne peut pas copier complètement et de manière reproductible un processus, et il n'y a pas d'accès à la copie sur écriture. Pour combler cette lacune, uClinux implémente vfork() Lorsque le processus parent appelle vfork() pour créer un processus enfant, les deux processus partagent tout leur espace mémoire, y compris la pile. Le processus enfant s'exécute à la place du processus parent (le processus parent est déjà en veille à ce moment-là) jusqu'à ce que le processus enfant appelle exitI() pour quitter, ou appelle exec() pour exécuter un nouveau processus, auquel moment le fichier exécutable sera chargé. Même si le processus n'est qu'une copie du processus parent, ce processus ne peut être évité. Lorsque le processus enfant exécute exit() ou exec(), le processus enfant utilise le réveil pour réveiller le processus parent, et le processus parent continue son exécution.

Modifications du noyau dans l'architecture générale :

Dans la version d'uCLinux, le répertoire /linux/mmnommu a remplacé le répertoire /linux/mm. Le premier est un sous-système de gestion de mémoire modifié qui a supprimé la dépendance matérielle de la MMU et ajouté le. le logiciel du noyau lui-même fournit des fonctions de gestion interne de base.

De nombreux sous-systèmes doivent être modifiés, ajoutés ou réécrits. Les processus d'allocation et de libération de la mémoire du noyau et de l'utilisateur doivent être réimplémentés, et la prise en charge de l'interaction/pagination transparente est également supprimée dans le noyau. ajout d'un module de support de programme pour prendre en charge le "code indépendant du noyau (PIC)" et utilisé un nouveau format de code objet binaire, appelé format plat, pour prendre en charge le PIC (avec un en-tête très compact

Le noyau fournit également un support au format ELF). module de chargement de programme pour prendre en charge les programmes exécutables utilisant des adresses de base fixes. Les deux modes ont leurs propres avantages et inconvénients. Le PIC traditionnel fonctionne rapidement et a un code compact, mais a des limites de taille de code. Par exemple, la version relative 16 bits du Motorola 68K. L'architecture Jump limite la taille des programmes PIC à 32 Ko maximum. Les codes de programme répertoriés à l'aide d'une adresse de base fixe pendant l'exécution n'ont pas de limite de taille. Cependant, lorsque Chen Xu est chargé par le noyau, cela entraîne une surcharge système pour le noyau. développeurs On dit que uCLinux n'est fondamentalement pas différent de Linux. La seule différence est qu'il ne peut pas utiliser la gestion de la mémoire fournie par MMU. En fait, cela n'a aucun impact sur le noyau. Tous les formats de fichiers exécutables standards sous Linux ne sont pas pris en charge. uCLinux, car ce format utilise également certaines fonctions de la mémoire virtuelle. uCLinux utilise un autre format plat est un format de fichier exécutable concis et efficace. Il contient du code et des données exécutables, ainsi que certaines informations relocalisables nécessaires. charger dans n'importe quel emplacement de la mémoire.

Résumé : Dans le processus de portage de l'application sur uClinux et d'écriture du code nous-mêmes, nous nous concentrerons toujours sur ces fonctionnalités :

1 Dans la configuration Lorsque cela est possible, vous devez sélectionner —désactiver. -shared et —enable-static lors de la configuration.

2. Remplacez toutes les occurrences de fork() dans le code source par vfork();

3 Dans les options du compilateur et de compilation Makefile Cross, ajoutez -Wl, -elf2flt au fichier. options de lien. Même s'il ne s'agit que d'une option de liaison, je prends soin de préciser cette option dans LDFLAGS et CFLAGS, et même dans CC.​

Apprentissage recommandé : Tutoriel vidéo Linux

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!