Le patron de Linux, Linus Torvalds, a envisagé de mettre fin à la prise en charge de l'architecture du processeur i486 dans le noyau Linux.L'ancienne architecture a fait l'objet de discussions il y a quelques jours dans un fil de discussion qui examinait comment le noyau pouvait mieux gérer les listes les moins récemment utilisées (LRU) - un moyen de suivre les pages mémoire.
Alors que Torvalds enquêtait sur le code des contributeurs, il semble avoir été frustré par la nécessité d'inclure des solutions de contournement adaptées aux processeurs plus anciens. Il a donc suggéré de mettre fin à la prise en charge de l'ancien kit, ce qui pourrait être un moyen plus simple de résoudre les problèmes de mémoire.
« Nous nous sommes débarrassés du support i386 en 2012. Peut-être est-il temps de se débarrasser du support i486 en 2022*? » a-t-il écrit.
Envoyé par Linus Torvalds
Nous le faisons déjà (certes mal - ce n'est pas SMP safe [ndlr. c'est-à-dire qu'il s'exécutera correctement même face à un accès simultané à partir de plusieurs threads d'exécution], mais les machines SMP de classe 486 n'ont jamais été prises en charge même si elles existaient techniquement), voir
arch/x86/lib/cmpxchg8b_emu.S
arch/x86/lib/atomic64_386_32.S
est un code assez dégoûtant.
Mais c'est toute l'autre infrastructure pour soutenir cela qui n'est qu'un poids inutile. Faites un Grep [ndlr. une commande qui permet de rechercher un mot ou un modèle et la ou les lignes qui le contiennent seront imprimées] avec CONFIG_X86_CMPXCHG64 et X86_FEATURE_CX8.
Nous avons déjà des tests de couverture de plus en plus mauvais pour x86-32 - et votre exemple de MIPS ne renforce vraiment pas votre argument tant que ça, parce que MIPS n'a jamais été très largement utilisé en premier lieu, et n'affecte aucun développement de ligne principale.
Les fonctionnalités étranges et la sélection du processeur n'aident vraiment pas.
Honnêtement, cela ne me dérangerait pas de mettre à niveau les exigences minimales à au moins M586TSC - laissant certains de ces premiers clones de "faux Pentium" derrière aussi. Parce que 'rdtsc' est probablement un problème encore pire que CMPXCHG8B.
En fait, je ne comprends pas du tout pourquoi les noyaux actuels fonctionnent sur un i486, puisqu'il ressemble à exit_to_user_mode_prepare -> arch_exit_to_user_mode_prepare et finit par avoir une instruction 'rdtsc' inconditionnelle.
Je suppose que vous n'avez pas activé RANDOMIZE_KSTACK_OFFSET*? En d'autres termes, notre support non-Pentium est ACTIVEMENT BOGUÉ ET BRISÉ en ce moment.
Ce n'est pas une question théorique, mais plutôt un « regardez, ça n'a jamais été testé et ça ne peut pas réellement fonctionner », que personne n'a jamais remarqué parce que personne ne s'en soucie vraiment.
Il m'a fallu quelques minutes de « chasse » pour trouver ce truc et c'est juste un exemple de la rupture de notre support actuel.
Ce code RANDOMIZE_KSTACK_OFFSET *compile* très bien. C'est juste qu'il ne fonctionne pas réellement.
C'est le genre de fardeau d'entretien que nous ne devrions tout simplement pas avoir - aucun développeur ne s'en soucie réellement (correctement), personne ne teste vraiment cette situation (également correctement - c'est du matériel ancien et non pertinent), mais cela signifie également que le code ne fonctionne pas au hasard.
Linus
arch/x86/lib/cmpxchg8b_emu.S
arch/x86/lib/atomic64_386_32.S
est un code assez dégoûtant.
Mais c'est toute l'autre infrastructure pour soutenir cela qui n'est qu'un poids inutile. Faites un Grep [ndlr. une commande qui permet de rechercher un mot ou un modèle et la ou les lignes qui le contiennent seront imprimées] avec CONFIG_X86_CMPXCHG64 et X86_FEATURE_CX8.
Nous avons déjà des tests de couverture de plus en plus mauvais pour x86-32 - et votre exemple de MIPS ne renforce vraiment pas votre argument tant que ça, parce que MIPS n'a jamais été très largement utilisé en premier lieu, et n'affecte aucun développement de ligne principale.
Les fonctionnalités étranges et la sélection du processeur n'aident vraiment pas.
Honnêtement, cela ne me dérangerait pas de mettre à niveau les exigences minimales à au moins M586TSC - laissant certains de ces premiers clones de "faux Pentium" derrière aussi. Parce que 'rdtsc' est probablement un problème encore pire que CMPXCHG8B.
En fait, je ne comprends pas du tout pourquoi les noyaux actuels fonctionnent sur un i486, puisqu'il ressemble à exit_to_user_mode_prepare -> arch_exit_to_user_mode_prepare et finit par avoir une instruction 'rdtsc' inconditionnelle.
Je suppose que vous n'avez pas activé RANDOMIZE_KSTACK_OFFSET*? En d'autres termes, notre support non-Pentium est ACTIVEMENT BOGUÉ ET BRISÉ en ce moment.
Ce n'est pas une question théorique, mais plutôt un « regardez, ça n'a jamais été testé et ça ne peut pas réellement fonctionner », que personne n'a jamais remarqué parce que personne ne s'en soucie vraiment.
Il m'a fallu quelques minutes de « chasse » pour trouver ce truc et c'est juste un exemple de la rupture de notre support actuel.
Ce code RANDOMIZE_KSTACK_OFFSET *compile* très bien. C'est juste qu'il ne fonctionne pas réellement.
C'est le genre de fardeau d'entretien que nous ne devrions tout simplement pas avoir - aucun développeur ne s'en soucie réellement (correctement), personne ne teste vraiment cette situation (également correctement - c'est du matériel ancien et non pertinent), mais cela signifie également que le code ne fonctionne pas au hasard.
Linus
Plus loin dans le fil de discussion, il est revenu sur le sujet avec les observations suivantes :
« Donc je ne pense vraiment plus que le matériel de classe i486 soit pertinent. Oui, je suis sûr que cela existe (Maciej étant un exemple), mais du point de vue du développement du noyau, je ne pense pas qu'ils soient vraiment pertinents. À un moment donné, les gens les ont comme pièces de musée. Ils pourraient tout aussi bien gérer des noyaux de musée ».
Il faut dire que l'architecture i486 a fait ses débuts en 1989 et a été remplacée par le Pentium d'Intel en 1993. Intel s'est débarrassé du i486 en 2007 et aujourd'hui, sa célèbre base de données de produits Ark détaillée ne contient aucune mention de la famille de processeurs.
Quiconque utilise encore les appareils s'est depuis longtemps résigné à le faire sans assistance, sans la possibilité d'acquérir un nouveau kit ou que les développeurs de logiciels réfléchissent à la plate-forme.
Pour plus de détails, l'Intel 80486 (i486, 486) est un microprocesseur de la famille des x86, fabriqué par Intel. Il est lancé en 1989. Du point de vue de l'architecture de processeur, le 80486 est très semblable à son prédécesseur immédiat, l'Intel 80386, avec l'ajout de quelques instructions supplémentaires. C'est donc une architecture CISC.
Du point de vue de la microarchitecture, il y avait à l'époque une grande amélioration : une mémoire cache unifiée intégrée d'instructions et de données, en option une unité de calcul en virgule flottante (FPU) intégrée, et une unité d'interface de bus améliorée. En outre, dans des conditions optimales, le cœur du processeur pouvait soutenir un rythme d'exécution d'une instruction par cycle. Ces améliorations permettaient approximativement de doubler la vitesse d'exécution par rapport à un 80386 à la même fréquence de base. Cependant, quelques modèles bas de gamme (Intel 80486SX) étaient plus lents que les 80386 les plus rapides.
Une version 25 MHz est présentée en avril 1989, une version 33 MHz en mai 1990, et une version 50 MHz en juin 1991.
Source : Linus Torvalds
Et vous ?
Comprenez-vous la décision de Linus Torvalds visant à se débarrasser de la prise en charge de cette architecture ? 
