Je ne suis pas sûr qu'il existe une distrib Linux pour amstrad CPC...
Par contre ce qui est beaucoup plus sûr, c'est de faire tourner un emulateur Amstrad sous Linux, là du coup tu t'amuses car beaucoup de jeux sont disponibles sur le net, tu peux même apprendre l'assembleur Z80 (il y a beaucoup de doc sur le net), bref tu peux essayer de coder toi même tes propres jeux.
Les architectures matérielles supportées par le noyau sont nombreuses et variées, et comportent notament les motorola 68000 "m86k" (atari,amiga,mac...). Mais de mémoire, aucun des processeurs 8 bits de l'époque n'est supporté. Ni les motorola 680x (TO7, MO5...), ni l'intel 8080, ni son successeur de Zilog Z80 (CPC, Game boy...). Coté intel, il faut attendre le 80386 ("i386"), et des portages sont tentés pour le 8086...
Non il n'y a aucune distribution linux pour Z80.
A mon avis il doit manquer pas mal de fonctionalités au CPU pour pouvoir supporter linux
Et pire que ça, il n'y a pas, non plus, de distribution netBSD et netBSD est réputé pour être le systeme d'exploitation disponible sur le plus grand nombre de plateformes matérielles. ( http://www.netbsd.org/Ports/#ports-by-cpu )
Le mieux est de chercher sur des sites spécialisés CPC pour voir ce qu'il peut y avoir de disponible en dehors du système d'origine.
Ensuite, ce n'est certainement pas au CPU qu'il manque des fonctionnalités. Étant donné que la quasi-totalité du système est écrite en C, je suis tenté de dire que la seule chose que l'on demande au microprocesseur est de donner la possibilité d'implémenter une pile. Le reste se fait tout seul, et les pilotes pour les différents types de matériels ne réclameront pas des centaines de kilo-octets.
En revanche, c'est l'absence d'une mémoire conséquente qui fera le plus défaut au système. Si en plus, celui-ci ne peut pas se rabattre non plus sur un disque dur, je crains qu'il faille abandonner l'idée d'un système d'exploitation générique sur les vieilles machines.
Voir plutôt ce qui se fait avec OS-9 par exemple, un peu plus haut.
Supporter est du jargon informatique. C'est marrant, supporter te gêne et pas CPU ...
C'est bien au CPU qu'il manque des fonctionalités. Même si la quasi-totalité du système est écrite en C, au final c'est bien en assembleur que les instructions sont traduites et il faut donc que le CPU supporte des fonctions essentielles comme, par exemple, un équivalent de l'instruction TAS ( Test And Set ) pour pouvoir implementer des mecanismes de lock, integre un MMU et aît pas mal d'autres fonctionalités comme la possibilité d'adresser une taille mémoire suffisante pour au moins pouvoir booter le kernel.
Supporter est du jargon informatique. C'est marrant, supporter te gêne et pas CPU ...
CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.
« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».
Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.
Même si la quasi-totalité du système est écrite en C, au final c'est bien en assembleur que les instructions sont traduites et il faut donc que le CPU supporte des fonctions essentielles comme, par exemple, un équivalent de l'instruction TAS ( Test And Set ) pour pouvoir implementer des mecanismes de lock
Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.
integre un MMU et aît pas mal d'autres fonctionalités comme la possibilité d'adresser une taille mémoire suffisante pour au moins pouvoir booter le kernel.
Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.
La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.
Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.
Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.
Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid.
Je maintiens que c'est du jargon. Le jour ou les articles concernant l'informatique seront écrits en bon français sans aucun jargon, fais moi signe.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.
Effectivement, que le MMU soit intégré ou pas, ne pouvoir adresser que 64 Ko de mémoire en continu est problématique pour linux.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives
Oui l'instruction TAS n'exite pas sur x86 mais il y a une astuce qui permet de la simuler. Quand tu dis "tu vires les inerruptions" il faut quand même qu'il y ait un moyen de le faire de façon non-interruptible sinon le serpent se mors la queue et tu limites juste les risques.
S'il n'existe aucune architecture CPU 8 bits qui soit supportée ( ça va, pas trop mal ? ) sous linux il doit bien y avoir des raisons propres aux CPU 8 bits non ?
Si OS/9 a tourné/tourne sur le Z80 et pas linux ça prouve effectivement qu'on peut faire tourner un système, de plus temp-réel, sur un Z80 mais qu'il y a d'autres éléments requis pour pouvoir faire tourner linux qui ne sont pas réunis sur un Z80, même secondé par un ou plusieurs dispositifs externes.
Je maintiens que c'est du jargon. Le jour ou les articles concernant l'informatique seront écrits en bon français sans aucun jargon, fais moi signe.
Ce n'est pas une raison. Ils le seront quand ceux qui les écrivent feront l'effort.
il faut quand même qu'il y ait un moyen de le faire de façon non-interruptible sinon le serpent se mors la queue et tu limites juste les risques.
Tous les microprocesseurs, même les plus anciens, savent faire cela en une opération et l'inhibition des IRQ est faite en interne, mais cela n'est même pas nécessaire. Si, par exemple, tu mets en place un système d'inhibition en tamponnant la ligne d'IRQ avec un transistor dont la base est attaquée par un port, tu n'as pas besoin d'une opération atomique pour activer la bonne ligne. Une interruption peut avoir lieu pendant que tu récupères l'état du port, se dérouler normalement et te rendre la main pour que tu modifies le bit qui t'intéresse et mette le port à jour. L'atomicité de l'exécution débute au moment où la ligne est mise à l'état adéquat. C'est d'ailleurs le principe de toute transaction.
Une interruption peut avoir lieu pendant que tu récupères l'état du port, se dérouler normalement et te rendre la main pour que tu modifies le bit qui t'intéresse et mette le port à jour. L'atomicité de l'exécution débute au moment où la ligne est mise à l'état adéquat. C'est d'ailleurs le principe de toute transaction.
Si tu peux être interrompu entre le test et le set potentiellement tu peux l'être par une autre tàche qui fait la même chose que la première et ensuite les deux tâches se déroulent en pensant être la seule à avoir posé un lock.
Le fait de rajouter un transistor ne change rien à l'affaire.
Non ?
Tu confonds encore. Selon ton dernier post, on parlait de la mise en état hors-interruption, pas de l'opération qui la nécessite. Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction). Donc :
1) Tu inhibes les interruptions avec le nombre d'instructions que tu veux (et qui peuvent donc être interrompues).
2) À l'issue du point précédent, les interruptions ont été inhibées. Peu importe à quel moment, l'état est garanti à la frontière entre 1) et 2). Tu fais ton opération atomique (ton lock ou n'importe quoi d'autre) en utilisant à nouveau le nombre d'instructions qui te chante.
3) Tu réactives les interruptions.
Il ne s'agissait pas non plus d' « ajouter » un transistor. Tous les microprocesseurs huit bits, à ma connaissance, sont capables d'inhiber les interruptions eux-mêmes et en une seule opération, ce qui les rend en principe éligibles à la mise en ½uvre de systèmes d'exploitation évolués, selon tes critères. L'exemple donné mettait en lumière le fait que même dans le pire des cas (CPU dépourvu de cette simple fonctionalité), il est parfaitement possible de garantir l'atomicité recherchée.
Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction).
Et si justement, c'est ce que tu n'arrives pas à comprendre. Tu ne peux pas dérouler le nombre d'instructions que tu veux jusqu'à avoir bloqué les interruptions du système et ensuite dérouler ta tâche sans aller droit dans le mur.
Et je ne confond rien, c'est toi qui ne comprend pas le mécanisme necessaire à la pose d'un lock. Cette opération doit absolument se faire de façon non interruptible par une autre tâche du système donc de façon atomique. Non interruptible ET extremement bref pour ne pas perturber le fonctionnement du système dans son ensemble. Le test ET le set. Sous peine de voir 2 tâches poser un lock simultanément et ensuite continuer leur fonctionnement en tenant pour acquis qu'elles sont propriétaires du lock pendant le temps que se déroulent les opérations suivant la pose du lock jusqu'à sa desactivation.
Il faut que le noyau ou des tâches plus prioritaires puissent interrompre une tâche ayant posé un lock sous peine de graves problèmes de non prise en compte d'évenements, voire de gel du système tout entier si la tâche ayant posé un lock boucle.
De plus c'est incohérent de bloquer toutes les interruptions juste pour avoir un pseudo-lock. De mémoire seulement windows 3.11 faisait une énormité comme ça.
C'est des concepts de base des systèmes temps-réel qui te paraîtraient évidents si les avais un peu pratiqué.
Pour en revenir au sujet du post. Il faut que ce mécanisme soit possible pour faire fonctionner linux. On ne peut pas faire fonctionner de système multi-tâche ,même non temps-réel, sans un moyen valide de poser des locks.
# Et pour ZX81 ? Ca t'intéresse ?
Posté par xavier dumont . Évalué à 1.
[^] # Re: Et pour ZX81 ? Ca t'intéresse ?
Posté par Thibault Baldetti . Évalué à 1.
@+
# Difficile..
Posté par Dabowl_92 . Évalué à 6.
Je ne suis pas sûr qu'il existe une distrib Linux pour amstrad CPC...
Par contre ce qui est beaucoup plus sûr, c'est de faire tourner un emulateur Amstrad sous Linux, là du coup tu t'amuses car beaucoup de jeux sont disponibles sur le net, tu peux même apprendre l'assembleur Z80 (il y a beaucoup de doc sur le net), bref tu peux essayer de coder toi même tes propres jeux.
# Ca existe?
Posté par jimee (site web personnel) . Évalué à 8.
Les architectures matérielles supportées par le noyau sont nombreuses et variées, et comportent notament les motorola 68000 "m86k" (atari,amiga,mac...). Mais de mémoire, aucun des processeurs 8 bits de l'époque n'est supporté. Ni les motorola 680x (TO7, MO5...), ni l'intel 8080, ni son successeur de Zilog Z80 (CPC, Game boy...). Coté intel, il faut attendre le 80386 ("i386"), et des portages sont tentés pour le 8086...
[^] # une piste: uclinux
Posté par Nicolas P. . Évalué à 3.
Un problème majeur vient du fait que même uclinux a besoin d'environ 500 Mo de RAM.
Source :
http://www.google.com/search?q=8bits+site%3Auclinux.org
puis :
http://mailman.uclinux.org/pipermail/uclinux-dev/2003-May/01(...)
[^] # GNIIIIIIIIIIIIIIIIIII !!!!!
Posté par totof2000 . Évalué à 4.
Met-là à la poubelle ton uuclinux! Meme debian a besoin de moins pour démarrer !!!
je crois qu'il faut remplacer ton Mo par Ko. :)
[^] # Re: Oups !!!!!
Posté par Nicolas P. . Évalué à 4.
Eh oui! Même que l'ordinateur qui a servi a aller sur la Lune n'avait que 32 Ko de RAM!!!
(source : http://www.deadtroll.com/index2.html?/video/ossuckscable.htm(...) )
[^] # Re: Ca existe? -> OS9
Posté par Obsidian . Évalué à 5.
Les premiers tests ont été très prometteurs.
http://os9.forler.ch/
[^] # OS9 != MacOS-9
Posté par Nicolas P. . Évalué à 2.
Pour les non-initiés (comme moi), l'OS9 dont il est question n'est PAS MacOS-9.
Source :
http://fr.wikipedia.org/wiki/OS-9
[^] # Re: OS9 != MacOS-9
Posté par NeoX . Évalué à 2.
# Et non ...
Posté par mururoa69 . Évalué à 1.
A mon avis il doit manquer pas mal de fonctionalités au CPU pour pouvoir supporter linux
Et pire que ça, il n'y a pas, non plus, de distribution netBSD et netBSD est réputé pour être le systeme d'exploitation disponible sur le plus grand nombre de plateformes matérielles. ( http://www.netbsd.org/Ports/#ports-by-cpu )
Le mieux est de chercher sur des sites spécialisés CPC pour voir ce qu'il peut y avoir de disponible en dehors du système d'origine.
[^] # Re: Et non ...
Posté par Obsidian . Évalué à 4.
« Supporter », dans ce sens-ci, n'est pas français ! Dites « prendre en charge », « reconnaître » ou « soutenir », selon les cas. http://linuxfr.org/comments/620840.html#620840 .
Ensuite, ce n'est certainement pas au CPU qu'il manque des fonctionnalités. Étant donné que la quasi-totalité du système est écrite en C, je suis tenté de dire que la seule chose que l'on demande au microprocesseur est de donner la possibilité d'implémenter une pile. Le reste se fait tout seul, et les pilotes pour les différents types de matériels ne réclameront pas des centaines de kilo-octets.
En revanche, c'est l'absence d'une mémoire conséquente qui fera le plus défaut au système. Si en plus, celui-ci ne peut pas se rabattre non plus sur un disque dur, je crains qu'il faille abandonner l'idée d'un système d'exploitation générique sur les vieilles machines.
Voir plutôt ce qui se fait avec OS-9 par exemple, un peu plus haut.
[^] # Re: Et non ...
Posté par Nicolas P. . Évalué à 1.
L'un des objectifs de ucLinux est justement de porter le noyau aux processeurs et microcontrôleurs qui en sont dépourvus.
[^] # Re: Et non ...
Posté par mururoa69 . Évalué à 0.
C'est bien au CPU qu'il manque des fonctionalités. Même si la quasi-totalité du système est écrite en C, au final c'est bien en assembleur que les instructions sont traduites et il faut donc que le CPU supporte des fonctions essentielles comme, par exemple, un équivalent de l'instruction TAS ( Test And Set ) pour pouvoir implementer des mecanismes de lock, integre un MMU et aît pas mal d'autres fonctionalités comme la possibilité d'adresser une taille mémoire suffisante pour au moins pouvoir booter le kernel.
[^] # Re: Et non ...
Posté par Obsidian . Évalué à 2.
CPU est un sigle pour « Central Processing Unit ». La seule chose incorrecte à la limite, c'est l'emploi du masculin à la place du féminin, par rapprochement avec « microprocesseur », masculin lui aussi.
« Supporter », ce n'est pas du jargon, c'est une faute de français, et c'est également très laid. C'est une traduction ridicule et mot-à-mot de « to support », qui ne signifie pas la même chose du tout. Et surtout, si cela passe à la limite en français parce qu'on est inondé de termes techniques anglo-saxons, ce n'est absolument pas réversible. Le sens français ne passera absolument pas en anglais en utilisant « to support ».
Ce serait à la limite du jargon si les gens se souvenaient encore d'où cela vient, et surtout que ce n'est pas du tout français. Notre langue est suffisamment riche pour que l'on se permette d'utiliser les termes consacrés, surtout quand ils ont toujours existé. Invoquer le jargon, c'est essayer de justifier une mauvaise habitude plutôt que la pallier.
Visiblement cela ne passe pas, donc je développe : Cela ne change absolument rien. D'une part, les locks ne sont en aucun cas gérés par le langage C lui-même, et d'autre part, la seule chose dont le C fasse fortement usage est le système de pile (qui peut même être implémenté à partir de rien à partir du moment où tu peux faire un adressage indexé). Les logiciels écrits en C, notamment Linux, ne sont donc pas du tout censés être articulés autour d'une spécificité d'un microprocesseur donné.
Pour TAS, cette fonction n'existe pas en une seule instruction sur i386. D'une manière générale, si tu as besoin d'effectuer une opération atomique, tu vires les interruptions, tu fais ton travail et tu les réactives. Évidement, avoir une instruction indivisible par essence est cent fois plus efficace, surtout qu'un programme en mode utilisateur qui aurait besoin de faire ce genre de chose devrait demander la permission au noyau, mais c'est nullement une condition vitale pour en écrire un, et heureusement : avec ce genre ce raisonnement, on n'aurait jamais connu Unix en 1970, ni même l'essor du RISC.
Déjà, j'ai l'impression que pas mal de monde confond les MMUs en général et le mode protégé (comme on l'appelle chez Intel) en particulier.
http://en.wikipedia.org/wiki/Memory_management_unit
La principale tâche d'une MMU est la résolution d'adresses virtuelles en adresses physiques. Un tel circuit n'a absolument pas besoin de se trouver embarqué dans le CPU lui-même pour fonctionner. Le système de banques mémoire, par exemple, était extrêmement répandu sur les 8 bits.
Pour la protection des pages, là encore, même s'il est beaucoup plus pratique de l'embarquer, le système peut très bien être externalisé. Un contrôleur de bus peut très bien bloquer la transmission d'un accès et envoyer un signal d'interruption au processeur, qui lui peut même se permettre de l'ignorer superbement sans que l'intégrité du système soit compromise un instant.
Dans tous les cas, non seulement sa gestion ne relève pas de l'assembleur en particulier, mais cela ne relève même pas intrinsèquement du langage C. C'est une fonction qui consiste à aller déposer une table quelque part en mémoire et qui peut être réalisée par n'importe quel moyen.
Pour la taille mémoire, si tu relis mon commentaire, tu t'apercevras que c'est mon argument principal. Pour la manière dont elle est agencée, c'est au compilateur C de s'en accomoder.
[^] # Re: Et non ...
Posté par mururoa69 . Évalué à -1.
Je maintiens que c'est du jargon. Le jour ou les articles concernant l'informatique seront écrits en bon français sans aucun jargon, fais moi signe.
Effectivement, que le MMU soit intégré ou pas, ne pouvoir adresser que 64 Ko de mémoire en continu est problématique pour linux.
Oui l'instruction TAS n'exite pas sur x86 mais il y a une astuce qui permet de la simuler. Quand tu dis "tu vires les inerruptions" il faut quand même qu'il y ait un moyen de le faire de façon non-interruptible sinon le serpent se mors la queue et tu limites juste les risques.
S'il n'existe aucune architecture CPU 8 bits qui soit supportée ( ça va, pas trop mal ? ) sous linux il doit bien y avoir des raisons propres aux CPU 8 bits non ?
Si OS/9 a tourné/tourne sur le Z80 et pas linux ça prouve effectivement qu'on peut faire tourner un système, de plus temp-réel, sur un Z80 mais qu'il y a d'autres éléments requis pour pouvoir faire tourner linux qui ne sont pas réunis sur un Z80, même secondé par un ou plusieurs dispositifs externes.
[^] # Re: Et non ...
Posté par Obsidian . Évalué à 2.
Ce n'est pas une raison. Ils le seront quand ceux qui les écrivent feront l'effort.
Tous les microprocesseurs, même les plus anciens, savent faire cela en une opération et l'inhibition des IRQ est faite en interne, mais cela n'est même pas nécessaire. Si, par exemple, tu mets en place un système d'inhibition en tamponnant la ligne d'IRQ avec un transistor dont la base est attaquée par un port, tu n'as pas besoin d'une opération atomique pour activer la bonne ligne. Une interruption peut avoir lieu pendant que tu récupères l'état du port, se dérouler normalement et te rendre la main pour que tu modifies le bit qui t'intéresse et mette le port à jour. L'atomicité de l'exécution débute au moment où la ligne est mise à l'état adéquat. C'est d'ailleurs le principe de toute transaction.
[^] # Deadlock
Posté par mururoa69 . Évalué à -1.
Si tu peux être interrompu entre le test et le set potentiellement tu peux l'être par une autre tàche qui fait la même chose que la première et ensuite les deux tâches se déroulent en pensant être la seule à avoir posé un lock.
Le fait de rajouter un transistor ne change rien à l'affaire.
Non ?
[^] # Re: Deadlock
Posté par Obsidian . Évalué à 2.
Non.
Tu confonds encore. Selon ton dernier post, on parlait de la mise en état hors-interruption, pas de l'opération qui la nécessite. Pour faire simple : L'opération assurant l'atomicité d'une transaction n'a pas besoin d'être elle-même atomique (car elle ne fait pas partie implicite de la transaction). Donc :
1) Tu inhibes les interruptions avec le nombre d'instructions que tu veux (et qui peuvent donc être interrompues).
2) À l'issue du point précédent, les interruptions ont été inhibées. Peu importe à quel moment, l'état est garanti à la frontière entre 1) et 2). Tu fais ton opération atomique (ton lock ou n'importe quoi d'autre) en utilisant à nouveau le nombre d'instructions qui te chante.
3) Tu réactives les interruptions.
Il ne s'agissait pas non plus d' « ajouter » un transistor. Tous les microprocesseurs huit bits, à ma connaissance, sont capables d'inhiber les interruptions eux-mêmes et en une seule opération, ce qui les rend en principe éligibles à la mise en ½uvre de systèmes d'exploitation évolués, selon tes critères. L'exemple donné mettait en lumière le fait que même dans le pire des cas (CPU dépourvu de cette simple fonctionalité), il est parfaitement possible de garantir l'atomicité recherchée.
[^] # Re: Deadlock
Posté par mururoa69 . Évalué à -1.
Et si justement, c'est ce que tu n'arrives pas à comprendre. Tu ne peux pas dérouler le nombre d'instructions que tu veux jusqu'à avoir bloqué les interruptions du système et ensuite dérouler ta tâche sans aller droit dans le mur.
Et je ne confond rien, c'est toi qui ne comprend pas le mécanisme necessaire à la pose d'un lock. Cette opération doit absolument se faire de façon non interruptible par une autre tâche du système donc de façon atomique. Non interruptible ET extremement bref pour ne pas perturber le fonctionnement du système dans son ensemble. Le test ET le set. Sous peine de voir 2 tâches poser un lock simultanément et ensuite continuer leur fonctionnement en tenant pour acquis qu'elles sont propriétaires du lock pendant le temps que se déroulent les opérations suivant la pose du lock jusqu'à sa desactivation.
Il faut que le noyau ou des tâches plus prioritaires puissent interrompre une tâche ayant posé un lock sous peine de graves problèmes de non prise en compte d'évenements, voire de gel du système tout entier si la tâche ayant posé un lock boucle.
De plus c'est incohérent de bloquer toutes les interruptions juste pour avoir un pseudo-lock. De mémoire seulement windows 3.11 faisait une énormité comme ça.
C'est des concepts de base des systèmes temps-réel qui te paraîtraient évidents si les avais un peu pratiqué.
Pour en revenir au sujet du post. Il faut que ce mécanisme soit possible pour faire fonctionner linux. On ne peut pas faire fonctionner de système multi-tâche ,même non temps-réel, sans un moyen valide de poser des locks.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.