je travaille plus particuli=E8rement sur OpenBSD, mais je teste les
divers BSD.
A cette effet, je souhaite me fabriquer une release pour chacun des
trois et repartir apr=E8s des tests foireux sur des releases =E0 jours et
propres.
Un syst=E8me BSD poss=E8de t-il un fonctionnement SMP asymetrique ?
Dans l'affirmative, me confirmez-vous la n=E9cessit=E9 pour l'obtention
d'une plateforme SMP, de recompiler le USERLAND ?
Dans l'affirmative y-at-il des options particuli=E8re pour la compil du
USERLAND =E0 indiquer ou cela ce d=E9tecte automatiquement?
pour le syst=E8me de port cela est-il identique ?
Grosso modo, je veux =EAtre certain que, si je fabrique des releases, et
fourni les paquetages via l'arbre des ports necessaire =E0 mes tests,
lorsque je repars d'une release, mon syst=E8me soit SMP.
seconde =E9tape, basculer cela sur des Proliants DL bi pro / quad core.
Derni=E8re question, les *bsd prennent il en charge la partie EMT64 des
cette architecture mat=E9riel ?
Ben, Net & Open bossent sur le smp depuis plus de 5 ans quand même, et en l'absence d'infos complémentaires sur l'implémentation choisie, la question reste valide.
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Eric Masson <emss@free.fr> wrote:
talon@lpthe.jussieu.fr (Michel Talon) writes:
'Re,
à part 5 ans de travail des développeurs ...
Ben, Net & Open bossent sur le smp depuis plus de 5 ans quand même, et
en l'absence d'infos complémentaires sur l'implémentation choisie, la
question reste valide.
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup
de boulot de fait dans -current.
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
Ben, Net & Open bossent sur le smp depuis plus de 5 ans quand même, et en l'absence d'infos complémentaires sur l'implémentation choisie, la question reste valide.
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Eric Masson
Manuel Bouyer writes:
'Lut,
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
Il y a une synthèse disponible quelque part sur les options qui ont été choisies ? C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une autre option ?
-- D> on trouve parfois un informaticien copulant avec la HP Laser C'est en pensant à eux qu'Apple a prévu des iMac rose bondon, avec deux ports FireWire à l'arrière... -+-SP in <http://www.le-gnu.net> Et la grenouille, elle en dit quoi -+-
Manuel Bouyer <bouyer@nerim.net> writes:
'Lut,
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup
de boulot de fait dans -current.
Il y a une synthèse disponible quelque part sur les options qui ont été
choisies ?
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une
autre option ?
--
D> on trouve parfois un informaticien copulant avec la HP Laser
C'est en pensant à eux qu'Apple a prévu des iMac rose bondon, avec deux
ports FireWire à l'arrière...
-+-SP in <http://www.le-gnu.net> Et la grenouille, elle en dit quoi -+-
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
Il y a une synthèse disponible quelque part sur les options qui ont été choisies ? C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une autre option ?
-- D> on trouve parfois un informaticien copulant avec la HP Laser C'est en pensant à eux qu'Apple a prévu des iMac rose bondon, avec deux ports FireWire à l'arrière... -+-SP in <http://www.le-gnu.net> Et la grenouille, elle en dit quoi -+-
espie
In article <g2rmt3$q1s$, Manuel Bouyer wrote:
Eric Masson wrote:
(Michel Talon) writes:
'Re,
à part 5 ans de travail des développeurs ...
Ben, Net & Open bossent sur le smp depuis plus de 5 ans quand même, et en l'absence d'infos complémentaires sur l'implémentation choisie, la question reste valide.
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
Cote Open, de ce que j'en sais, on est plus en train d'essayer de nettoyer des bouts MD et de les passer MI. Les archi biscornues qui tournent maintenant en SMP ont aide a voir plus clair, et je crois qu'il y a pas mal d'optimisation cote gestion de cache et carte memoire.
Perso, je m'occupe beaucoup plus de la partie userland, et notre make a fait un enorme bond en avant cote SMP, au point qu'il marche en make -j4 avec tout l'arbre src et X (et c'est make qui a bouge, hein... pas d'adaptations bizarres du source, juste des corrections de bugs de makefile ou il manquait des dependances). J'ai encore un probleme complique a resoudre, et apres j'ai bon espoir que 90% de l'arbre des ports se laisse faire egalement.
Mais bon, j'ai pas du SMP de bourrin. Sur mon portable, le build est passe d'1h10 a 40mn, c'est quand meme appreciable...
In article <g2rmt3$q1s$1@biggoron.nerim.net>,
Manuel Bouyer <bouyer@nerim.net> wrote:
Eric Masson <emss@free.fr> wrote:
talon@lpthe.jussieu.fr (Michel Talon) writes:
'Re,
à part 5 ans de travail des développeurs ...
Ben, Net & Open bossent sur le smp depuis plus de 5 ans quand même, et
en l'absence d'infos complémentaires sur l'implémentation choisie, la
question reste valide.
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup
de boulot de fait dans -current.
Cote Open, de ce que j'en sais, on est plus en train d'essayer de nettoyer
des bouts MD et de les passer MI. Les archi biscornues qui tournent
maintenant en SMP ont aide a voir plus clair, et je crois qu'il y a pas
mal d'optimisation cote gestion de cache et carte memoire.
Perso, je m'occupe beaucoup plus de la partie userland, et notre make a
fait un enorme bond en avant cote SMP, au point qu'il marche en make -j4
avec tout l'arbre src et X (et c'est make qui a bouge, hein... pas
d'adaptations bizarres du source, juste des corrections de bugs de makefile
ou il manquait des dependances).
J'ai encore un probleme complique a resoudre, et apres j'ai bon espoir que
90% de l'arbre des ports se laisse faire egalement.
Mais bon, j'ai pas du SMP de bourrin. Sur mon portable, le build est passe
d'1h10 a 40mn, c'est quand meme appreciable...
Ben, Net & Open bossent sur le smp depuis plus de 5 ans quand même, et en l'absence d'infos complémentaires sur l'implémentation choisie, la question reste valide.
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
Cote Open, de ce que j'en sais, on est plus en train d'essayer de nettoyer des bouts MD et de les passer MI. Les archi biscornues qui tournent maintenant en SMP ont aide a voir plus clair, et je crois qu'il y a pas mal d'optimisation cote gestion de cache et carte memoire.
Perso, je m'occupe beaucoup plus de la partie userland, et notre make a fait un enorme bond en avant cote SMP, au point qu'il marche en make -j4 avec tout l'arbre src et X (et c'est make qui a bouge, hein... pas d'adaptations bizarres du source, juste des corrections de bugs de makefile ou il manquait des dependances). J'ai encore un probleme complique a resoudre, et apres j'ai bon espoir que 90% de l'arbre des ports se laisse faire egalement.
Mais bon, j'ai pas du SMP de bourrin. Sur mon portable, le build est passe d'1h10 a 40mn, c'est quand meme appreciable...
Manuel Bouyer
Eric Masson wrote:
Manuel Bouyer writes:
'Lut,
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
Il y a une synthèse disponible quelque part sur les options qui ont été choisies ?
Pas a ma conaissance. Il faudrait rechercher les posts de en particulier
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une autre option ?
C'est assez proche de freebsd et solaris (en particulier des primitives ont ete reprises de solaris).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Eric Masson <emss@free.fr> wrote:
Manuel Bouyer <bouyer@nerim.net> writes:
'Lut,
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup
de boulot de fait dans -current.
Il y a une synthèse disponible quelque part sur les options qui ont été
choisies ?
Pas a ma conaissance. Il faudrait rechercher les posts de ad@netbsd.org
en particulier
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une
autre option ?
C'est assez proche de freebsd et solaris (en particulier des primitives ont
ete reprises de solaris).
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
NetBSD est en passe de virer le big lock aussi; il y a deja eu beaucoup de boulot de fait dans -current.
Il y a une synthèse disponible quelque part sur les options qui ont été choisies ?
Pas a ma conaissance. Il faudrait rechercher les posts de en particulier
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une autre option ?
C'est assez proche de freebsd et solaris (en particulier des primitives ont ete reprises de solaris).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Vincent
Ensuite, il y a encore quelques problemes sur certains systemes, typiquement lies aux bugs de l'ACPI qui fait que parfois, activer le 2e processeur et les suivants sont assez complexes...
M'en parlez pas. NetBSD-current est infoutu de démarrer le deuxième Core 2 sur ma machine DELL. Le plus gros pb, c'est que je suis infoutu de trouver de la doc pour savoir où il faut regarder ce qui merde. Le SMP, c'est quasiment pas documenté. Je me demande si les *BSD ne se repassent pas du code entre eux, et qui a pondu le premier code SMP pour x86...
V.
Ensuite, il y a encore quelques problemes sur certains systemes, typiquement
lies aux bugs de l'ACPI qui fait que parfois, activer le 2e processeur et
les suivants sont assez complexes...
M'en parlez pas. NetBSD-current est infoutu de démarrer le deuxième Core
2 sur ma machine DELL. Le plus gros pb, c'est que je suis infoutu de
trouver de la doc pour savoir où il faut regarder ce qui merde. Le SMP,
c'est quasiment pas documenté. Je me demande si les *BSD ne se repassent
pas du code entre eux, et qui a pondu le premier code SMP pour x86...
Ensuite, il y a encore quelques problemes sur certains systemes, typiquement lies aux bugs de l'ACPI qui fait que parfois, activer le 2e processeur et les suivants sont assez complexes...
M'en parlez pas. NetBSD-current est infoutu de démarrer le deuxième Core 2 sur ma machine DELL. Le plus gros pb, c'est que je suis infoutu de trouver de la doc pour savoir où il faut regarder ce qui merde. Le SMP, c'est quasiment pas documenté. Je me demande si les *BSD ne se repassent pas du code entre eux, et qui a pondu le premier code SMP pour x86...
V.
Vincent
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une autre option ? C'est assez proche de freebsd et solaris (en particulier des primitives ont
ete reprises de solaris).
Globalement, si j'ai bien compris, cela revient à créer des sémaphores d'interblocage qui peuvent fonctionner aussi bien en mode « normal » qu'en mode d'interruption.
V.
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une
autre option ?
C'est assez proche de freebsd et solaris (en particulier des primitives ont
ete reprises de solaris).
Globalement, si j'ai bien compris, cela revient à créer des sémaphores
d'interblocage qui peuvent fonctionner aussi bien en mode « normal »
qu'en mode d'interruption.
C'est proche de la méthode FreeBSD, BSD/OS ou alors c'est vraiment une autre option ? C'est assez proche de freebsd et solaris (en particulier des primitives ont
ete reprises de solaris).
Globalement, si j'ai bien compris, cela revient à créer des sémaphores d'interblocage qui peuvent fonctionner aussi bien en mode « normal » qu'en mode d'interruption.
V.
espie
In article <4852300c$0$28495$, Vincent wrote:
Ensuite, il y a encore quelques problemes sur certains systemes, typiquement lies aux bugs de l'ACPI qui fait que parfois, activer le 2e processeur et les suivants sont assez complexes...
M'en parlez pas. NetBSD-current est infoutu de démarrer le deuxième Core 2 sur ma machine DELL. Le plus gros pb, c'est que je suis infoutu de trouver de la doc pour savoir où il faut regarder ce qui merde. Le SMP, c'est quasiment pas documenté. Je me demande si les *BSD ne se repassent pas du code entre eux, et qui a pondu le premier code SMP pour x86...
Ben evidemment que les BSD se repassent du code entre eux, c'est marque partout dans les messages de commit.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons possibles, la plupart correspondent a des bugs varies de l'architecture PC. En gros, si on fait les choses dans un ordre different de windows, on est a peu pres sur que ca vaut causer des problemes sur au moins certaines machines.
Sur Open, les gens qui bossent sur ce bout sont tres, tres courageux: il faut des tonnes et des tonnes de test pour s'assurer que chaque modif ne va pas casser 15 machines et en reparer 3...
Je sais que, sur mon thinkpad, il fallait imperativement activer l'acpi pour que le 2e proc daigne demarrer: sans acpi, le bios restait dans un mode `compatible vieux coucou', et le proc refusait obstinement de se laisser voir.
In article <4852300c$0$28495$426a34cc@news.free.fr>,
Vincent <10.50@free.fr> wrote:
Ensuite, il y a encore quelques problemes sur certains systemes, typiquement
lies aux bugs de l'ACPI qui fait que parfois, activer le 2e processeur et
les suivants sont assez complexes...
M'en parlez pas. NetBSD-current est infoutu de démarrer le deuxième Core
2 sur ma machine DELL. Le plus gros pb, c'est que je suis infoutu de
trouver de la doc pour savoir où il faut regarder ce qui merde. Le SMP,
c'est quasiment pas documenté. Je me demande si les *BSD ne se repassent
pas du code entre eux, et qui a pondu le premier code SMP pour x86...
Ben evidemment que les BSD se repassent du code entre eux, c'est marque
partout dans les messages de commit.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons
possibles, la plupart correspondent a des bugs varies de l'architecture PC.
En gros, si on fait les choses dans un ordre different de windows, on est
a peu pres sur que ca vaut causer des problemes sur au moins certaines
machines.
Sur Open, les gens qui bossent sur ce bout sont tres, tres courageux: il
faut des tonnes et des tonnes de test pour s'assurer que chaque modif ne va
pas casser 15 machines et en reparer 3...
Je sais que, sur mon thinkpad, il fallait imperativement activer l'acpi
pour que le 2e proc daigne demarrer: sans acpi, le bios restait dans un
mode `compatible vieux coucou', et le proc refusait obstinement de se
laisser voir.
Ensuite, il y a encore quelques problemes sur certains systemes, typiquement lies aux bugs de l'ACPI qui fait que parfois, activer le 2e processeur et les suivants sont assez complexes...
M'en parlez pas. NetBSD-current est infoutu de démarrer le deuxième Core 2 sur ma machine DELL. Le plus gros pb, c'est que je suis infoutu de trouver de la doc pour savoir où il faut regarder ce qui merde. Le SMP, c'est quasiment pas documenté. Je me demande si les *BSD ne se repassent pas du code entre eux, et qui a pondu le premier code SMP pour x86...
Ben evidemment que les BSD se repassent du code entre eux, c'est marque partout dans les messages de commit.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons possibles, la plupart correspondent a des bugs varies de l'architecture PC. En gros, si on fait les choses dans un ordre different de windows, on est a peu pres sur que ca vaut causer des problemes sur au moins certaines machines.
Sur Open, les gens qui bossent sur ce bout sont tres, tres courageux: il faut des tonnes et des tonnes de test pour s'assurer que chaque modif ne va pas casser 15 machines et en reparer 3...
Je sais que, sur mon thinkpad, il fallait imperativement activer l'acpi pour que le 2e proc daigne demarrer: sans acpi, le bios restait dans un mode `compatible vieux coucou', et le proc refusait obstinement de se laisser voir.
Vincent
Ben evidemment que les BSD se repassent du code entre eux, c'est marque partout dans les messages de commit.
C'est bien jusqu'à un certain point, mais cela pose le problème de savoir si les copistes savent ce qu'ils font, particulièrement dans ce domaine extrêmement proche du matériel.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons possibles, la plupart correspondent a des bugs varies de l'architecture PC. En gros, si on fait les choses dans un ordre different de windows, on est a peu pres sur que ca vaut causer des problemes sur au moins certaines machines.
Le pb c'est que ça boote correctement sur FreeBSD mais pas sur Net.
Je sais que, sur mon thinkpad, il fallait imperativement activer l'acpi pour que le 2e proc daigne demarrer: sans acpi, le bios restait dans un mode `compatible vieux coucou', et le proc refusait obstinement de se laisser voir.
Sur ce PC, c'est très bizarre. Sur une version bien particulière de current, que je garde précieusement (mais je suis bloqué dans les évolutions du noyau et de l'userland) et sur laquelle je boote, le drapeau SMPDEBUG provoque un appel de DDB (le debugger interne au noyau) quand le second proc refuse de s'initialiser. Il suffit que je tape juste "cont" et ça marche, le deuxième proc. part, tout va bien. Le problème, c'est que 1. c'est de la bidouille, 2. les nouvelles versions de -current n'ont pas ce comportement et plantent systématiquement.
C'est pour ça que je voulais mettre mon nez dedans (le matériel, c'est ma spécialité au départ), mais je n'arrive tout simplement pas à trouver la doc qui va bien.
Vincent
Ben evidemment que les BSD se repassent du code entre eux, c'est marque
partout dans les messages de commit.
C'est bien jusqu'à un certain point, mais cela pose le problème de
savoir si les copistes savent ce qu'ils font, particulièrement dans ce
domaine extrêmement proche du matériel.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons
possibles, la plupart correspondent a des bugs varies de l'architecture PC.
En gros, si on fait les choses dans un ordre different de windows, on est
a peu pres sur que ca vaut causer des problemes sur au moins certaines
machines.
Le pb c'est que ça boote correctement sur FreeBSD mais pas sur Net.
Je sais que, sur mon thinkpad, il fallait imperativement activer l'acpi
pour que le 2e proc daigne demarrer: sans acpi, le bios restait dans un
mode `compatible vieux coucou', et le proc refusait obstinement de se
laisser voir.
Sur ce PC, c'est très bizarre. Sur une version bien particulière de
current, que je garde précieusement (mais je suis bloqué dans les
évolutions du noyau et de l'userland) et sur laquelle je boote, le
drapeau SMPDEBUG provoque un appel de DDB (le debugger interne au noyau)
quand le second proc refuse de s'initialiser. Il suffit que je tape
juste "cont" et ça marche, le deuxième proc. part, tout va bien. Le
problème, c'est que 1. c'est de la bidouille, 2. les nouvelles versions
de -current n'ont pas ce comportement et plantent systématiquement.
C'est pour ça que je voulais mettre mon nez dedans (le matériel, c'est
ma spécialité au départ), mais je n'arrive tout simplement pas à trouver
la doc qui va bien.
Ben evidemment que les BSD se repassent du code entre eux, c'est marque partout dans les messages de commit.
C'est bien jusqu'à un certain point, mais cela pose le problème de savoir si les copistes savent ce qu'ils font, particulièrement dans ce domaine extrêmement proche du matériel.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons possibles, la plupart correspondent a des bugs varies de l'architecture PC. En gros, si on fait les choses dans un ordre different de windows, on est a peu pres sur que ca vaut causer des problemes sur au moins certaines machines.
Le pb c'est que ça boote correctement sur FreeBSD mais pas sur Net.
Je sais que, sur mon thinkpad, il fallait imperativement activer l'acpi pour que le 2e proc daigne demarrer: sans acpi, le bios restait dans un mode `compatible vieux coucou', et le proc refusait obstinement de se laisser voir.
Sur ce PC, c'est très bizarre. Sur une version bien particulière de current, que je garde précieusement (mais je suis bloqué dans les évolutions du noyau et de l'userland) et sur laquelle je boote, le drapeau SMPDEBUG provoque un appel de DDB (le debugger interne au noyau) quand le second proc refuse de s'initialiser. Il suffit que je tape juste "cont" et ça marche, le deuxième proc. part, tout va bien. Le problème, c'est que 1. c'est de la bidouille, 2. les nouvelles versions de -current n'ont pas ce comportement et plantent systématiquement.
C'est pour ça que je voulais mettre mon nez dedans (le matériel, c'est ma spécialité au départ), mais je n'arrive tout simplement pas à trouver la doc qui va bien.
Vincent
espie
In article <485236c2$0$28495$, Vincent wrote:
Ben evidemment que les BSD se repassent du code entre eux, c'est marque partout dans les messages de commit.
C'est bien jusqu'à un certain point, mais cela pose le problème de savoir si les copistes savent ce qu'ils font, particulièrement dans ce domaine extrêmement proche du matériel.
Parce que tu sais mieux qu'eux, tu penses ?
Je ne m'avancerais pas pour les voisins, mais chez Open, je te garantis que les gars qui committent dans ces coins de l'OS savent tres tres bien ce qu'ils font.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons possibles, la plupart correspondent a des bugs varies de l'architecture PC. En gros, si on fait les choses dans un ordre different de windows, on est a peu pres sur que ca vaut causer des problemes sur au moins certaines machines.
Le pb c'est que ça boote correctement sur FreeBSD mais pas sur Net.
Ca veut dire que Free fait les choses dans un ordre legerement different, et que ca marche... ca peut tres bien etre un bug dans le bios de ta machine, et le code de Net qui le titille dans le sens inverse du sens du poil. Tout comme ca peut etre un bug dans le code de Net...
C'est pour ça que je voulais mettre mon nez dedans (le matériel, c'est ma spécialité au départ), mais je n'arrive tout simplement pas à trouver la doc qui va bien.
Oh, tu as donc decouvert le vrai probleme. Felicitations.
Tout simplement, une enorme partie du fonctionnement de ce materiel n'est PAS documente, ou tres mal documente, ou pas du tout disponible si tu ne bosses pas pour le constructeur.
C'est pour ca que ca ne marche pas toujours cote logiciel libre (entre autres).
Il faut aussi noter qu'assez souvent, FreeBSD et Linux ne jouent pas avec les memes regles: ils ont des bases utilisateurs assez etendues, et pas mal de developpeurs prets a toutes sortes de compromissions, ce qui fait qu'assez souvent, ils ont vendu leur ame (ou presque) et obtenu de la doc sous NDA qui permet de faire marcher certains trucs...
In article <485236c2$0$28495$426a34cc@news.free.fr>,
Vincent <10.50@free.fr> wrote:
Ben evidemment que les BSD se repassent du code entre eux, c'est marque
partout dans les messages de commit.
C'est bien jusqu'à un certain point, mais cela pose le problème de
savoir si les copistes savent ce qu'ils font, particulièrement dans ce
domaine extrêmement proche du matériel.
Parce que tu sais mieux qu'eux, tu penses ?
Je ne m'avancerais pas pour les voisins, mais chez Open, je te garantis
que les gars qui committent dans ces coins de l'OS savent tres tres bien
ce qu'ils font.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons
possibles, la plupart correspondent a des bugs varies de l'architecture PC.
En gros, si on fait les choses dans un ordre different de windows, on est
a peu pres sur que ca vaut causer des problemes sur au moins certaines
machines.
Le pb c'est que ça boote correctement sur FreeBSD mais pas sur Net.
Ca veut dire que Free fait les choses dans un ordre legerement different,
et que ca marche... ca peut tres bien etre un bug dans le bios de ta machine,
et le code de Net qui le titille dans le sens inverse du sens du poil.
Tout comme ca peut etre un bug dans le code de Net...
C'est pour ça que je voulais mettre mon nez dedans (le matériel, c'est
ma spécialité au départ), mais je n'arrive tout simplement pas à trouver
la doc qui va bien.
Oh, tu as donc decouvert le vrai probleme. Felicitations.
Tout simplement, une enorme partie du fonctionnement de ce materiel n'est
PAS documente, ou tres mal documente, ou pas du tout disponible si tu
ne bosses pas pour le constructeur.
C'est pour ca que ca ne marche pas toujours cote logiciel libre (entre
autres).
Il faut aussi noter qu'assez souvent, FreeBSD et Linux ne jouent pas
avec les memes regles: ils ont des bases utilisateurs assez etendues, et
pas mal de developpeurs prets a toutes sortes de compromissions, ce qui
fait qu'assez souvent, ils ont vendu leur ame (ou presque) et obtenu de la
doc sous NDA qui permet de faire marcher certains trucs...
Ben evidemment que les BSD se repassent du code entre eux, c'est marque partout dans les messages de commit.
C'est bien jusqu'à un certain point, mais cela pose le problème de savoir si les copistes savent ce qu'ils font, particulièrement dans ce domaine extrêmement proche du matériel.
Parce que tu sais mieux qu'eux, tu penses ?
Je ne m'avancerais pas pour les voisins, mais chez Open, je te garantis que les gars qui committent dans ces coins de l'OS savent tres tres bien ce qu'ils font.
Pour le 2e core qui ne demarre pas, il y a une quantite affolante de raisons possibles, la plupart correspondent a des bugs varies de l'architecture PC. En gros, si on fait les choses dans un ordre different de windows, on est a peu pres sur que ca vaut causer des problemes sur au moins certaines machines.
Le pb c'est que ça boote correctement sur FreeBSD mais pas sur Net.
Ca veut dire que Free fait les choses dans un ordre legerement different, et que ca marche... ca peut tres bien etre un bug dans le bios de ta machine, et le code de Net qui le titille dans le sens inverse du sens du poil. Tout comme ca peut etre un bug dans le code de Net...
C'est pour ça que je voulais mettre mon nez dedans (le matériel, c'est ma spécialité au départ), mais je n'arrive tout simplement pas à trouver la doc qui va bien.
Oh, tu as donc decouvert le vrai probleme. Felicitations.
Tout simplement, une enorme partie du fonctionnement de ce materiel n'est PAS documente, ou tres mal documente, ou pas du tout disponible si tu ne bosses pas pour le constructeur.
C'est pour ca que ca ne marche pas toujours cote logiciel libre (entre autres).
Il faut aussi noter qu'assez souvent, FreeBSD et Linux ne jouent pas avec les memes regles: ils ont des bases utilisateurs assez etendues, et pas mal de developpeurs prets a toutes sortes de compromissions, ce qui fait qu'assez souvent, ils ont vendu leur ame (ou presque) et obtenu de la doc sous NDA qui permet de faire marcher certains trucs...
Vincent
C'est bien jusqu'à un certain point, mais cela pose le problème de savoir si les copistes savent ce qu'ils font, particulièrement dans ce domaine extrêmement proche du matériel. Parce que tu sais mieux qu'eux, tu penses ?
Je n'ai pas dit ça. D'ailleurs, personnellement, je suis bien plus habitué à l'archi 68000 qu'à l'Intel x86 pour des raisons historiques.
Je ne m'avancerais pas pour les voisins, mais chez Open, je te garantis que les gars qui committent dans ces coins de l'OS savent tres tres bien ce qu'ils font.
Je pense que c'est le cas aussi chez Net, en tout cas Andrew Doran et Matthias. De toute façon, c'est clair, si tu te plantes sur le démarrage, la machine ne boote pas, c'est facile à détecter (je grossis le trait à dessein) :)
Ca veut dire que Free fait les choses dans un ordre legerement different, et que ca marche... ca peut tres bien etre un bug dans le bios de ta machine, et le code de Net qui le titille dans le sens inverse du sens du poil. Tout comme ca peut etre un bug dans le code de Net...
Je pencherai davantage pour un pb dans le BIOS (mais ça boote aussi correctement sous Linux). Cependant, le fait que ça démarre après l'appel à DDB me laisse sceptique.
Tout simplement, une enorme partie du fonctionnement de ce materiel n'est PAS documente, ou tres mal documente, ou pas du tout disponible si tu ne bosses pas pour le constructeur.
Bon, d'un autre côté, la doc de l'ACPI a l'air d'être librement téléchargeable. Mais est-ce que l'initialisation d'un multiprocessseur x86 se limite à l'ACPI ?
Il faut aussi noter qu'assez souvent, FreeBSD et Linux ne jouent pas avec les memes regles: ils ont des bases utilisateurs assez etendues, et pas mal de developpeurs prets a toutes sortes de compromissions, ce qui fait qu'assez souvent, ils ont vendu leur ame (ou presque) et obtenu de la doc sous NDA qui permet de faire marcher certains trucs...
Oui, mais alors ça me ramène à ma première question. Sans péjuger de la compétence des développeurs chez Net ou Open, cela signifie qu'il faut parfois qu'ils appliquent des patches tirés des noyaux de Free ou Linux sans pouvoir matériellement en vérifier l'exactitude ou la cohérence...
V.
C'est bien jusqu'à un certain point, mais cela pose le problème de
savoir si les copistes savent ce qu'ils font, particulièrement dans ce
domaine extrêmement proche du matériel.
Parce que tu sais mieux qu'eux, tu penses ?
Je n'ai pas dit ça. D'ailleurs, personnellement, je suis bien plus
habitué à l'archi 68000 qu'à l'Intel x86 pour des raisons historiques.
Je ne m'avancerais pas pour les voisins, mais chez Open, je te garantis
que les gars qui committent dans ces coins de l'OS savent tres tres bien
ce qu'ils font.
Je pense que c'est le cas aussi chez Net, en tout cas Andrew Doran et
Matthias. De toute façon, c'est clair, si tu te plantes sur le
démarrage, la machine ne boote pas, c'est facile à détecter (je grossis
le trait à dessein) :)
Ca veut dire que Free fait les choses dans un ordre legerement different,
et que ca marche... ca peut tres bien etre un bug dans le bios de ta machine,
et le code de Net qui le titille dans le sens inverse du sens du poil.
Tout comme ca peut etre un bug dans le code de Net...
Je pencherai davantage pour un pb dans le BIOS (mais ça boote aussi
correctement sous Linux). Cependant, le fait que ça démarre après
l'appel à DDB me laisse sceptique.
Tout simplement, une enorme partie du fonctionnement de ce materiel n'est
PAS documente, ou tres mal documente, ou pas du tout disponible si tu
ne bosses pas pour le constructeur.
Bon, d'un autre côté, la doc de l'ACPI a l'air d'être librement
téléchargeable. Mais est-ce que l'initialisation d'un multiprocessseur
x86 se limite à l'ACPI ?
Il faut aussi noter qu'assez souvent, FreeBSD et Linux ne jouent pas
avec les memes regles: ils ont des bases utilisateurs assez etendues, et
pas mal de developpeurs prets a toutes sortes de compromissions, ce qui
fait qu'assez souvent, ils ont vendu leur ame (ou presque) et obtenu de la
doc sous NDA qui permet de faire marcher certains trucs...
Oui, mais alors ça me ramène à ma première question. Sans péjuger de la
compétence des développeurs chez Net ou Open, cela signifie qu'il faut
parfois qu'ils appliquent des patches tirés des noyaux de Free ou Linux
sans pouvoir matériellement en vérifier l'exactitude ou la cohérence...
C'est bien jusqu'à un certain point, mais cela pose le problème de savoir si les copistes savent ce qu'ils font, particulièrement dans ce domaine extrêmement proche du matériel. Parce que tu sais mieux qu'eux, tu penses ?
Je n'ai pas dit ça. D'ailleurs, personnellement, je suis bien plus habitué à l'archi 68000 qu'à l'Intel x86 pour des raisons historiques.
Je ne m'avancerais pas pour les voisins, mais chez Open, je te garantis que les gars qui committent dans ces coins de l'OS savent tres tres bien ce qu'ils font.
Je pense que c'est le cas aussi chez Net, en tout cas Andrew Doran et Matthias. De toute façon, c'est clair, si tu te plantes sur le démarrage, la machine ne boote pas, c'est facile à détecter (je grossis le trait à dessein) :)
Ca veut dire que Free fait les choses dans un ordre legerement different, et que ca marche... ca peut tres bien etre un bug dans le bios de ta machine, et le code de Net qui le titille dans le sens inverse du sens du poil. Tout comme ca peut etre un bug dans le code de Net...
Je pencherai davantage pour un pb dans le BIOS (mais ça boote aussi correctement sous Linux). Cependant, le fait que ça démarre après l'appel à DDB me laisse sceptique.
Tout simplement, une enorme partie du fonctionnement de ce materiel n'est PAS documente, ou tres mal documente, ou pas du tout disponible si tu ne bosses pas pour le constructeur.
Bon, d'un autre côté, la doc de l'ACPI a l'air d'être librement téléchargeable. Mais est-ce que l'initialisation d'un multiprocessseur x86 se limite à l'ACPI ?
Il faut aussi noter qu'assez souvent, FreeBSD et Linux ne jouent pas avec les memes regles: ils ont des bases utilisateurs assez etendues, et pas mal de developpeurs prets a toutes sortes de compromissions, ce qui fait qu'assez souvent, ils ont vendu leur ame (ou presque) et obtenu de la doc sous NDA qui permet de faire marcher certains trucs...
Oui, mais alors ça me ramène à ma première question. Sans péjuger de la compétence des développeurs chez Net ou Open, cela signifie qu'il faut parfois qu'ils appliquent des patches tirés des noyaux de Free ou Linux sans pouvoir matériellement en vérifier l'exactitude ou la cohérence...
