Nous sommes sur sparc64. Que dirais-tu de comparer le nombre de package fonctionnels, plutot que ceux qui sont dans l'arbre des ports/pkgsrc et qui ne fonctionnent pas nécessairement, quand bien meme ils compilent, parce que sparc64 c'est du 64 bits sans droit a l'erreur...
Faut pas exagérer quand même. En 1997, les logiciels écrits avec les pieds avaient tendance à plantouiller gentiment sur Alpha parce que Alpha = 64 bits, et que les chimpanzés qui programment avaient alors du mal avec ce concept. Certes, l'Alpha arrange le coup en émulant les
Oui mais l'alpha, c'est du 64 avec droit à l'erreur, parce qu'il est petit boutiste.
Comme un petit dessin vaut mieux qu'un long discours, un code incorrect comme ceci :
int poca; void *yoke;
poca = (int) yoke;
utilisé, par exemples, par de mauvaises implémentations rpc, part directement dans le décor sur du 64 bits grand-boutiste, mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
En d'autres termes, je ne dis pas que NetBSD a tous (ou quasiment) ses ports qui marchent sur sparc64, mais je prétends que si ça ne marche pas, ce n'est pas une histoire de 64 bits vs 32 bits.
Et moi je pense que si, puisqu'il reste les bugs plus subtils. D'un autre côté avec le travail de stabilisation de pkgsrc des derniers mois on peut espérer qu'il n'en reste plus beaucoup, heureusement.
Nous sommes sur sparc64. Que dirais-tu de comparer le nombre de package
fonctionnels, plutot que ceux qui sont dans l'arbre des ports/pkgsrc et
qui ne fonctionnent pas nécessairement, quand bien meme ils compilent,
parce que sparc64 c'est du 64 bits sans droit a l'erreur...
Faut pas exagérer quand même. En 1997, les logiciels écrits avec les
pieds avaient tendance à plantouiller gentiment sur Alpha parce que
Alpha = 64 bits, et que les chimpanzés qui programment avaient alors
du mal avec ce concept. Certes, l'Alpha arrange le coup en émulant les
Oui mais l'alpha, c'est du 64 avec droit à l'erreur, parce qu'il est
petit boutiste.
Comme un petit dessin vaut mieux qu'un long discours, un code incorrect
comme ceci :
int poca;
void *yoke;
poca = (int) yoke;
utilisé, par exemples, par de mauvaises implémentations rpc, part
directement dans le décor sur du 64 bits grand-boutiste, mais marchotte
sur du 64 bits petit-boutiste, si le pointeur est une adresse
relativement basse (ce qui est en général le cas en userland sur alpha).
En d'autres termes, je ne dis pas que NetBSD a tous (ou quasiment) ses
ports qui marchent sur sparc64, mais je prétends que si ça ne marche pas,
ce n'est pas une histoire de 64 bits vs 32 bits.
Et moi je pense que si, puisqu'il reste les bugs plus subtils. D'un
autre côté avec le travail de stabilisation de pkgsrc des derniers mois
on peut espérer qu'il n'en reste plus beaucoup, heureusement.
Nous sommes sur sparc64. Que dirais-tu de comparer le nombre de package fonctionnels, plutot que ceux qui sont dans l'arbre des ports/pkgsrc et qui ne fonctionnent pas nécessairement, quand bien meme ils compilent, parce que sparc64 c'est du 64 bits sans droit a l'erreur...
Faut pas exagérer quand même. En 1997, les logiciels écrits avec les pieds avaient tendance à plantouiller gentiment sur Alpha parce que Alpha = 64 bits, et que les chimpanzés qui programment avaient alors du mal avec ce concept. Certes, l'Alpha arrange le coup en émulant les
Oui mais l'alpha, c'est du 64 avec droit à l'erreur, parce qu'il est petit boutiste.
Comme un petit dessin vaut mieux qu'un long discours, un code incorrect comme ceci :
int poca; void *yoke;
poca = (int) yoke;
utilisé, par exemples, par de mauvaises implémentations rpc, part directement dans le décor sur du 64 bits grand-boutiste, mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
En d'autres termes, je ne dis pas que NetBSD a tous (ou quasiment) ses ports qui marchent sur sparc64, mais je prétends que si ça ne marche pas, ce n'est pas une histoire de 64 bits vs 32 bits.
Et moi je pense que si, puisqu'il reste les bugs plus subtils. D'un autre côté avec le travail de stabilisation de pkgsrc des derniers mois on peut espérer qu'il n'en reste plus beaucoup, heureusement.
pornin
According to Miod Vallat :
mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
Je ne sais pas ce qu'il en est de NetBSD, mais sous FreeBSD/Alpha, les pointeurs ont tendance à déborder des 32 bits. Par exemple, je viens d'essayer le petit programme suivant :
ce qui veut dire que les pointeurs vers du code, des données statiques ou un bloc alloué avec malloc() dépassent les 32 bits (pas de beaucoup : ils en prennent 33) et que seule la pile est dans un espace sur 32 bits. Il s'agit d'un AXPpci33 (aka "NoName") sous FreeBSD-4.9. Je crois me rappeler que la situation est similaire sous Linux.
Du coup, il y a très peu de pointeurs qui survivent à un aller-retour vers le monde des "int". D'ailleurs, dans mon expérience (j'ai passé trois ans à travailler avec un Alpha sous Linux comme machine principale, et je l'ai administré "en profondeur", notamment avec des patchs maison sur le noyau, le serveur X11 et occasionnellement gcc), l'erreur la plus courante est un oubli d'inclusion de <stdlib.h>, qui faisait que malloc() était supposé renvoyer un "int" au lieu d'un "void *", et la sanction est une segfault immédiate.
--Thomas Pornin
According to Miod Vallat <miod@online.fr>:
mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une
adresse relativement basse (ce qui est en général le cas en userland
sur alpha).
Je ne sais pas ce qu'il en est de NetBSD, mais sous FreeBSD/Alpha,
les pointeurs ont tendance à déborder des 32 bits. Par exemple,
je viens d'essayer le petit programme suivant :
ce qui veut dire que les pointeurs vers du code, des données statiques
ou un bloc alloué avec malloc() dépassent les 32 bits (pas de beaucoup :
ils en prennent 33) et que seule la pile est dans un espace sur 32 bits.
Il s'agit d'un AXPpci33 (aka "NoName") sous FreeBSD-4.9. Je crois me
rappeler que la situation est similaire sous Linux.
Du coup, il y a très peu de pointeurs qui survivent à un aller-retour
vers le monde des "int". D'ailleurs, dans mon expérience (j'ai passé
trois ans à travailler avec un Alpha sous Linux comme machine principale,
et je l'ai administré "en profondeur", notamment avec des patchs maison
sur le noyau, le serveur X11 et occasionnellement gcc), l'erreur
la plus courante est un oubli d'inclusion de <stdlib.h>, qui faisait que
malloc() était supposé renvoyer un "int" au lieu d'un "void *", et la
sanction est une segfault immédiate.
mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
Je ne sais pas ce qu'il en est de NetBSD, mais sous FreeBSD/Alpha, les pointeurs ont tendance à déborder des 32 bits. Par exemple, je viens d'essayer le petit programme suivant :
ce qui veut dire que les pointeurs vers du code, des données statiques ou un bloc alloué avec malloc() dépassent les 32 bits (pas de beaucoup : ils en prennent 33) et que seule la pile est dans un espace sur 32 bits. Il s'agit d'un AXPpci33 (aka "NoName") sous FreeBSD-4.9. Je crois me rappeler que la situation est similaire sous Linux.
Du coup, il y a très peu de pointeurs qui survivent à un aller-retour vers le monde des "int". D'ailleurs, dans mon expérience (j'ai passé trois ans à travailler avec un Alpha sous Linux comme machine principale, et je l'ai administré "en profondeur", notamment avec des patchs maison sur le noyau, le serveur X11 et occasionnellement gcc), l'erreur la plus courante est un oubli d'inclusion de <stdlib.h>, qui faisait que malloc() était supposé renvoyer un "int" au lieu d'un "void *", et la sanction est une segfault immédiate.
--Thomas Pornin
Manuel Bouyer
Miod Vallat wrote:
Oui mais l'alpha, c'est du 64 avec droit à l'erreur, parce qu'il est petit boutiste.
Comme un petit dessin vaut mieux qu'un long discours, un code incorrect comme ceci :
int poca; void *yoke;
poca = (int) yoke;
utilisé, par exemples, par de mauvaises implémentations rpc, part directement dans le décor sur du 64 bits grand-boutiste, mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
Heu, pas sous NetBSD/alpha en tout cas: armandeche:/tmp>cat toto.c #include <stdio.h> #include <malloc.h> main() { char i; char *toto = &i; char *toto2 = (void*)malloc(1); printf("0x%lx 0x%lxn", (long)toto,(long)toto2); }
armandeche:/tmp>./toto 0x1fffff580 0x120014060 ces deux pointeurs ne tiennent pas dans un int.
En d'autres termes, je ne dis pas que NetBSD a tous (ou quasiment) ses ports qui marchent sur sparc64, mais je prétends que si ça ne marche pas, ce n'est pas une histoire de 64 bits vs 32 bits.
Et moi je pense que si, puisqu'il reste les bugs plus subtils. D'un autre côté avec le travail de stabilisation de pkgsrc des derniers mois on peut espérer qu'il n'en reste plus beaucoup, heureusement.
Il en reste probablement, mais je ne suis pas sur qu'il y en ai beaucoup plus que sur alpha (la ou ca peut faire une difference c'est sur int vs long, mais sur les pointeurs je ne pense pas - du moins pas sous NetBSD).
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Miod Vallat <miod@online.fr> wrote:
Oui mais l'alpha, c'est du 64 avec droit à l'erreur, parce qu'il est
petit boutiste.
Comme un petit dessin vaut mieux qu'un long discours, un code incorrect
comme ceci :
int poca;
void *yoke;
poca = (int) yoke;
utilisé, par exemples, par de mauvaises implémentations rpc, part
directement dans le décor sur du 64 bits grand-boutiste, mais marchotte
sur du 64 bits petit-boutiste, si le pointeur est une adresse
relativement basse (ce qui est en général le cas en userland sur alpha).
Heu, pas sous NetBSD/alpha en tout cas:
armandeche:/tmp>cat toto.c
#include <stdio.h>
#include <malloc.h>
main()
{
char i;
char *toto = &i;
char *toto2 = (void*)malloc(1);
printf("0x%lx 0x%lxn", (long)toto,(long)toto2);
}
armandeche:/tmp>./toto
0x1fffff580 0x120014060
ces deux pointeurs ne tiennent pas dans un int.
En d'autres termes, je ne dis pas que NetBSD a tous (ou quasiment) ses
ports qui marchent sur sparc64, mais je prétends que si ça ne marche pas,
ce n'est pas une histoire de 64 bits vs 32 bits.
Et moi je pense que si, puisqu'il reste les bugs plus subtils. D'un
autre côté avec le travail de stabilisation de pkgsrc des derniers mois
on peut espérer qu'il n'en reste plus beaucoup, heureusement.
Il en reste probablement, mais je ne suis pas sur qu'il y en ai beaucoup plus
que sur alpha (la ou ca peut faire une difference c'est sur int vs long, mais
sur les pointeurs je ne pense pas - du moins pas sous NetBSD).
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 24 ans d'experience feront toujours la difference
--
Oui mais l'alpha, c'est du 64 avec droit à l'erreur, parce qu'il est petit boutiste.
Comme un petit dessin vaut mieux qu'un long discours, un code incorrect comme ceci :
int poca; void *yoke;
poca = (int) yoke;
utilisé, par exemples, par de mauvaises implémentations rpc, part directement dans le décor sur du 64 bits grand-boutiste, mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
Heu, pas sous NetBSD/alpha en tout cas: armandeche:/tmp>cat toto.c #include <stdio.h> #include <malloc.h> main() { char i; char *toto = &i; char *toto2 = (void*)malloc(1); printf("0x%lx 0x%lxn", (long)toto,(long)toto2); }
armandeche:/tmp>./toto 0x1fffff580 0x120014060 ces deux pointeurs ne tiennent pas dans un int.
En d'autres termes, je ne dis pas que NetBSD a tous (ou quasiment) ses ports qui marchent sur sparc64, mais je prétends que si ça ne marche pas, ce n'est pas une histoire de 64 bits vs 32 bits.
Et moi je pense que si, puisqu'il reste les bugs plus subtils. D'un autre côté avec le travail de stabilisation de pkgsrc des derniers mois on peut espérer qu'il n'en reste plus beaucoup, heureusement.
Il en reste probablement, mais je ne suis pas sur qu'il y en ai beaucoup plus que sur alpha (la ou ca peut faire une difference c'est sur int vs long, mais sur les pointeurs je ne pense pas - du moins pas sous NetBSD).
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Manuel Bouyer
Thomas Pornin wrote:
According to Miod Vallat :
mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une adresse relativement basse (ce qui est en général le cas en userland sur alpha).
Je ne sais pas ce qu'il en est de NetBSD, mais sous FreeBSD/Alpha,
ha ben je viens juste de poster un test similaire :)
les pointeurs ont tendance à déborder des 32 bits. Par exemple, je viens d'essayer le petit programme suivant :
ce qui veut dire que les pointeurs vers du code, des données statiques ou un bloc alloué avec malloc() dépassent les 32 bits (pas de beaucoup : ils en prennent 33) et que seule la pile est dans un espace sur 32 bits.
Sous NetBSD, la pile aussi depasse les 32bits.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Thomas Pornin <pornin@nerim.net> wrote:
According to Miod Vallat <miod@online.fr>:
mais marchotte sur du 64 bits petit-boutiste, si le pointeur est une
adresse relativement basse (ce qui est en général le cas en userland
sur alpha).
Je ne sais pas ce qu'il en est de NetBSD, mais sous FreeBSD/Alpha,
ha ben je viens juste de poster un test similaire :)
les pointeurs ont tendance à déborder des 32 bits. Par exemple,
je viens d'essayer le petit programme suivant :
ce qui veut dire que les pointeurs vers du code, des données statiques
ou un bloc alloué avec malloc() dépassent les 32 bits (pas de beaucoup :
ils en prennent 33) et que seule la pile est dans un espace sur 32 bits.
Sous NetBSD, la pile aussi depasse les 32bits.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 24 ans d'experience feront toujours la difference
--
ce qui veut dire que les pointeurs vers du code, des données statiques ou un bloc alloué avec malloc() dépassent les 32 bits (pas de beaucoup : ils en prennent 33) et que seule la pile est dans un espace sur 32 bits.
Sous NetBSD, la pile aussi depasse les 32bits.
-- Manuel Bouyer NetBSD: 24 ans d'experience feront toujours la difference --
Thierry> ça laisse donc espérer une bonne foultitude de programmes qui Thierry> tournent en natif 64bits sur la prochaine "architecture de la Thierry> mort" (rapide et pas trop chère) avec les AMD64.
A ce sujet, cela ne vous parait pas bizarre que les amd64 soient bien accueillis, alors qu'Amd a fait ce qui est reproché à Intel depuis de longues années, à savoir étendre encore et toujours une architecture déficiente ?
Amha, le point positif de l'apparition des amd64 est une baisse probable des tarifs des concurrents 64 bits afin de ne pas se laisser distancer, et donc peut-être des ia64 ou G5 (j'aurais bien aimé ajouter les alphas, mais il me semble que hp est entrain de finir de tuer cette archi) à des tarifs démocratiques d'ici peu.
Eric Masson
-- Attends, s'il y a une toulousaine tu es gentil mais j'ai demandé le premier je crois. Premier arrivé premier servi quoi :-))))))))))) -+- GA in Guide du beauf primaire - "Envoyez la marchandise, VITE !"-+-
Thierry> ça laisse donc espérer une bonne foultitude de programmes qui
Thierry> tournent en natif 64bits sur la prochaine "architecture de la
Thierry> mort" (rapide et pas trop chère) avec les AMD64.
A ce sujet, cela ne vous parait pas bizarre que les amd64 soient bien
accueillis, alors qu'Amd a fait ce qui est reproché à Intel depuis de
longues années, à savoir étendre encore et toujours une architecture
déficiente ?
Amha, le point positif de l'apparition des amd64 est une baisse probable
des tarifs des concurrents 64 bits afin de ne pas se laisser distancer,
et donc peut-être des ia64 ou G5 (j'aurais bien aimé ajouter les alphas,
mais il me semble que hp est entrain de finir de tuer cette archi) à des
tarifs démocratiques d'ici peu.
Eric Masson
--
Attends, s'il y a une toulousaine tu es gentil mais j'ai demandé le
premier je crois.
Premier arrivé premier servi quoi :-)))))))))))
-+- GA in Guide du beauf primaire - "Envoyez la marchandise, VITE !"-+-
Thierry> ça laisse donc espérer une bonne foultitude de programmes qui Thierry> tournent en natif 64bits sur la prochaine "architecture de la Thierry> mort" (rapide et pas trop chère) avec les AMD64.
A ce sujet, cela ne vous parait pas bizarre que les amd64 soient bien accueillis, alors qu'Amd a fait ce qui est reproché à Intel depuis de longues années, à savoir étendre encore et toujours une architecture déficiente ?
Amha, le point positif de l'apparition des amd64 est une baisse probable des tarifs des concurrents 64 bits afin de ne pas se laisser distancer, et donc peut-être des ia64 ou G5 (j'aurais bien aimé ajouter les alphas, mais il me semble que hp est entrain de finir de tuer cette archi) à des tarifs démocratiques d'ici peu.
Eric Masson
-- Attends, s'il y a une toulousaine tu es gentil mais j'ai demandé le premier je crois. Premier arrivé premier servi quoi :-))))))))))) -+- GA in Guide du beauf primaire - "Envoyez la marchandise, VITE !"-+-
L'architecture Itanic qui est soutenue à bout de bras par Intel/HP depuis plus de 10ans, avec un succès très modéré est un exemple de saloperie que des boîtes arrogantes essaient de fourguer à tout ceux qui croient ce qui est marqué dans les brochures en papier glacé
Y'a aussi la volonté d'ouverture: si tu veux faire du code correct sur ia64, faut acheter le compilo du constructeur. AMD a fait tout ce qu'il a pu pour que sa puce soit bien supportée par les OS libres.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
L'architecture Itanic qui est soutenue à bout de bras par Intel/HP depuis
plus de 10ans, avec un succès très modéré est un exemple de saloperie que
des boîtes arrogantes essaient de fourguer à tout ceux qui croient ce qui
est marqué dans les brochures en papier glacé
Y'a aussi la volonté d'ouverture: si tu veux faire du code correct sur
ia64, faut acheter le compilo du constructeur. AMD a fait tout ce qu'il
a pu pour que sa puce soit bien supportée par les OS libres.
--
Emmanuel Dreyfus
Publicité subliminale: achetez ce livre!
http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
manu@netbsd.org
L'architecture Itanic qui est soutenue à bout de bras par Intel/HP depuis plus de 10ans, avec un succès très modéré est un exemple de saloperie que des boîtes arrogantes essaient de fourguer à tout ceux qui croient ce qui est marqué dans les brochures en papier glacé
Y'a aussi la volonté d'ouverture: si tu veux faire du code correct sur ia64, faut acheter le compilo du constructeur. AMD a fait tout ce qu'il a pu pour que sa puce soit bien supportée par les OS libres.
-- Emmanuel Dreyfus Publicité subliminale: achetez ce livre! http://www.eyrolles.com/php.informatique/Ouvrages/9782212112443.php3
Marc Dilasser
Marc Espie wrote:
In article <3fd4edc5$0$24028$, Marc Dilasser wrote:
Bonsoir,
J'ai un doute, si quelqu'un peut lever ça : il n'y a pas de packages NetBSD 1.6.1 pour les UltraSparc ? On doit tout prendre à partir des ports ?
Si c'est un modele supporte par OpenBSD, nous on a des packages pour la derniere release stable... a toi de voir, ca peut gagner du temps.
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5 (en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien inspiré de le copier chez Open.
Marc Dilasser
Marc Espie wrote:
In article <3fd4edc5$0$24028$626a54ce@news.free.fr>,
Marc Dilasser <marc.dilasser@free.fr> wrote:
Bonsoir,
J'ai un doute, si quelqu'un peut lever ça : il n'y a pas de packages
NetBSD 1.6.1 pour les UltraSparc ?
On doit tout prendre à partir des ports ?
Si c'est un modele supporte par OpenBSD, nous on a des packages pour la
derniere release stable...
a toi de voir, ca peut gagner du temps.
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un
OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5
(en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien
inspiré de le copier chez Open.
In article <3fd4edc5$0$24028$, Marc Dilasser wrote:
Bonsoir,
J'ai un doute, si quelqu'un peut lever ça : il n'y a pas de packages NetBSD 1.6.1 pour les UltraSparc ? On doit tout prendre à partir des ports ?
Si c'est un modele supporte par OpenBSD, nous on a des packages pour la derniere release stable... a toi de voir, ca peut gagner du temps.
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5 (en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien inspiré de le copier chez Open.
Marc Dilasser
Marc Bellon
In article (Dans l'article) <1g5o8lq.1vyi7w3d7hhoyN%, (Emmanuel Dreyfus) wrote (écrivait) :
Marc Dilasser wrote:
J'ai un doute, si quelqu'un peut lever ça : il n'y a pas de packages NetBSD 1.6.1 pour les UltraSparc ? On doit tout prendre à partir des ports ?
Visiblement oui, ou alors faire tourner les packages binaires sparc en compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum ! Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication intégrale des librairies partagées, plus certains modules du noyau, pour pouvoir supporter parallèlement des applications 64 et 32 bits.
L'OpenBSD qui tourne maintenant sur ma Sparc10 n'a pas l'air d'avoir ces librairies supplémentaires, et je suppose que tout essai de lancer une application sparc 32 bits serait immédiatement vouée à l'échec.
Mais je sauterais avec joie sur toute possibilité d'étendre le nombre d'applis capable de fonctionner sur ma bécane ! Par exemple, après avoir fait venir l'arbre des sources pour me faire un nouveau noyau, j'ai découvert que l'émulation pour le support d'applications Solaris n'était pas disponible sous Sparc64. Peut-être est-ce lié à cette question de la gestion du transfert entre modes 32 et 64 du processeur.
In article (Dans l'article) <1g5o8lq.1vyi7w3d7hhoyN%manu@netbsd.org>,
manu@netbsd.org (Emmanuel Dreyfus) wrote (écrivait) :
Marc Dilasser <marc.dilasser@free.fr> wrote:
J'ai un doute, si quelqu'un peut lever ça : il n'y a pas de packages NetBSD
1.6.1 pour les UltraSparc ?
On doit tout prendre à partir des ports ?
Visiblement oui, ou alors faire tourner les packages binaires sparc en
compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum !
Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication
intégrale des librairies partagées, plus certains modules du noyau,
pour pouvoir supporter parallèlement des applications 64 et 32 bits.
L'OpenBSD qui tourne maintenant sur ma Sparc10 n'a pas l'air d'avoir
ces librairies supplémentaires, et je suppose que tout essai de lancer
une application sparc 32 bits serait immédiatement vouée à l'échec.
Mais je sauterais avec joie sur toute possibilité d'étendre le nombre
d'applis capable de fonctionner sur ma bécane !
Par exemple, après avoir fait venir l'arbre des sources pour me faire
un nouveau noyau, j'ai découvert que l'émulation pour le support
d'applications Solaris n'était pas disponible sous Sparc64.
Peut-être est-ce lié à cette question de la gestion du transfert
entre modes 32 et 64 du processeur.
In article (Dans l'article) <1g5o8lq.1vyi7w3d7hhoyN%, (Emmanuel Dreyfus) wrote (écrivait) :
Marc Dilasser wrote:
J'ai un doute, si quelqu'un peut lever ça : il n'y a pas de packages NetBSD 1.6.1 pour les UltraSparc ? On doit tout prendre à partir des ports ?
Visiblement oui, ou alors faire tourner les packages binaires sparc en compatibilité binaire 32 bits, mais bon c'est moins bien.
Hum, hum ! Est-ce possible ?
Je veux dire, sous Solaris, il existe un système de duplication intégrale des librairies partagées, plus certains modules du noyau, pour pouvoir supporter parallèlement des applications 64 et 32 bits.
L'OpenBSD qui tourne maintenant sur ma Sparc10 n'a pas l'air d'avoir ces librairies supplémentaires, et je suppose que tout essai de lancer une application sparc 32 bits serait immédiatement vouée à l'échec.
Mais je sauterais avec joie sur toute possibilité d'étendre le nombre d'applis capable de fonctionner sur ma bécane ! Par exemple, après avoir fait venir l'arbre des sources pour me faire un nouveau noyau, j'ai découvert que l'émulation pour le support d'applications Solaris n'était pas disponible sous Sparc64. Peut-être est-ce lié à cette question de la gestion du transfert entre modes 32 et 64 du processeur.
espie
In article , Marc Bellon wrote:
Mais je sauterais avec joie sur toute possibilité d'étendre le nombre d'applis capable de fonctionner sur ma bécane ! Par exemple, après avoir fait venir l'arbre des sources pour me faire un nouveau noyau, j'ai découvert que l'émulation pour le support d'applications Solaris n'était pas disponible sous Sparc64. Peut-être est-ce lié à cette question de la gestion du transfert entre modes 32 et 64 du processeur.
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler les solaris recents, c'est leur nouveau mecanisme de communication inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme est incontournable pour l'emulation, vu qu'il est maintenant utilise par le DNS sous Solaris...
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits pur sur sparc64. Aucune idee du travail necessaire pour emuler des binaires 32 bits en plus.
In article <bellon-93FE87.17333310122003@asmodee.lpthe.jussieu.fr>,
Marc Bellon <bellon@lpthe.jussieu.fr> wrote:
Mais je sauterais avec joie sur toute possibilité d'étendre le nombre
d'applis capable de fonctionner sur ma bécane !
Par exemple, après avoir fait venir l'arbre des sources pour me faire
un nouveau noyau, j'ai découvert que l'émulation pour le support
d'applications Solaris n'était pas disponible sous Sparc64.
Peut-être est-ce lié à cette question de la gestion du transfert
entre modes 32 et 64 du processeur.
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler
les solaris recents, c'est leur nouveau mecanisme de communication
inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme
est incontournable pour l'emulation, vu qu'il est maintenant utilise par
le DNS sous Solaris...
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits
pur sur sparc64. Aucune idee du travail necessaire pour emuler des
binaires 32 bits en plus.
Mais je sauterais avec joie sur toute possibilité d'étendre le nombre d'applis capable de fonctionner sur ma bécane ! Par exemple, après avoir fait venir l'arbre des sources pour me faire un nouveau noyau, j'ai découvert que l'émulation pour le support d'applications Solaris n'était pas disponible sous Sparc64. Peut-être est-ce lié à cette question de la gestion du transfert entre modes 32 et 64 du processeur.
Je ne sais pas si NetBSD a le truc qui va bien, mais la difficulte d'emuler les solaris recents, c'est leur nouveau mecanisme de communication inter-processus, les doors (decrit entre autre dans Stevens): ce mecanisme est incontournable pour l'emulation, vu qu'il est maintenant utilise par le DNS sous Solaris...
Pour les aspects 32 bits, pour autant que je sache, OpenBSD est 64 bits pur sur sparc64. Aucune idee du travail necessaire pour emuler des binaires 32 bits en plus.
mips
On Wed, 10 Dec 2003 16:53:28 +0100 Marc Dilasser wrote:
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5(en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien inspiré de le copier chez Open.
Manque de bol ce dernier n'inspire pas OpenBSD :)
mips
On Wed, 10 Dec 2003 16:53:28 +0100
Marc Dilasser <marc.dilasser@free.fr> wrote:
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé
un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la
Station5(en 32 bits), en particulier le rc.d que je trouve
impeccable, serait bien inspiré de le copier chez Open.
On Wed, 10 Dec 2003 16:53:28 +0100 Marc Dilasser wrote:
En fait c'est ce que j'ai fait, c'est sur une Ultra1, j'ai installé un OpenBSD 3.4 mais je regrette un peu le NetBsd que j'avais sur la Station5(en 32 bits), en particulier le rc.d que je trouve impeccable, serait bien inspiré de le copier chez Open.
