D'autre part -même à s'en tenir au kernel- le fait que le noyau (Linux, xBSD, yBSD ...) puisse tourner sur une architecture donnée ne signifie pas que cette archicteture soit pleinement supportée.
Par exemple un noyau ne supportant que IA32 peut tourner sur un x86_64 type AMD64 en mode 32 bits, mais dans ce cas c'est, en toute honneteté, un support partiel de l'architecture. À ce sujet, puisqu'on parlait de support SPARC et de Debian, il y a une seule archive Debian/sparc, pas une archive 32 bits et une archive 64 bits -genre Debian/sparc et Debian/sparc64, comme c'est le cas en testing pour i386 32 et 64-: peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien).
Il en va de même des nombreuses extensions proposées par les processeurs modernes, type Intel/PAE, UltraSPARC/Stackghost, Intel/Silvervale, AMD/Pacifica etc. sans parler de la gestion (ou pas) du SMP et/ou du multihreading sur l'archi concernée ...
Donc dire qu'une distro ou un OS est "sparc-compatible", c'est trop peu dire.
Le Niagara (le proc dont il est question dans l'article) serait bien peu intéressant exploité par un OS tournant en 32 bits et ne sachant pas gérer le SMP SPARC, ni la virtualisation ...
Et puis comme le signalaient les posts parents, le kernel est une chose, le bootloader, la toolchain, les packages, ... en sont une autre: UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé (petit boutiste, majoritairement 32 bits, faibles contraintes d'alignement). Du coup, le travail des packageurs/distributions n'est pas négligeable. Ce n'est pas du « tout cuit ».
[^] # Re: Tanenbaum était un visionnaire ...
Posté par herodiade . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 5.
Par exemple un noyau ne supportant que IA32 peut tourner sur un x86_64 type AMD64 en mode 32 bits, mais dans ce cas c'est, en toute honneteté, un support partiel de l'architecture. À ce sujet, puisqu'on parlait de support SPARC et de Debian, il y a une seule archive Debian/sparc, pas une archive 32 bits et une archive 64 bits -genre Debian/sparc et Debian/sparc64, comme c'est le cas en testing pour i386 32 et 64-: peut-on en déduir que Debian n'utilise les processeurs UltraSPARC qu'en mode 32 bit ? (c'est une question hein, j'en sait rien).
Il en va de même des nombreuses extensions proposées par les processeurs modernes, type Intel/PAE, UltraSPARC/Stackghost, Intel/Silvervale, AMD/Pacifica etc. sans parler de la gestion (ou pas) du SMP et/ou du multihreading sur l'archi concernée ...
Donc dire qu'une distro ou un OS est "sparc-compatible", c'est trop peu dire.
Le Niagara (le proc dont il est question dans l'article) serait bien peu intéressant exploité par un OS tournant en 32 bits et ne sachant pas gérer le SMP SPARC, ni la virtualisation ...
Et puis comme le signalaient les posts parents, le kernel est une chose, le bootloader, la toolchain, les packages, ... en sont une autre: UltraSPARC est une archi délicate sur ce point, car grand boutiste, 64 bits, avec des contraintes d'alignement strictes, bref tout ce qu'il faut pour aimablement lever les bugs des applis développées sur pécé (petit boutiste, majoritairement 32 bits, faibles contraintes d'alignement). Du coup, le travail des packageurs/distributions n'est pas négligeable. Ce n'est pas du « tout cuit ».