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 ?
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 ?
A cote de ca, en gros l'OS s'annonce aupres de l'acpi. Mais la seule strategie raisonnable, c'est de s'annoncer comme etant du windows, parce qu'en pratique, c'est le seul mode que les constructeurs ont debuggue.
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...
Au moins chez nous, on ne joue pas a ca... on n'applique pas de patchs qu'on ne comprend pas.
In article <48524f21$0$32222$426a74cc@news.free.fr>,
Vincent <10.50@free.fr> wrote:
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 ?
A cote de ca, en gros l'OS s'annonce aupres de l'acpi.
Mais la seule strategie raisonnable, c'est de s'annoncer comme etant
du windows, parce qu'en pratique, c'est le seul mode que les constructeurs
ont debuggue.
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...
Au moins chez nous, on ne joue pas a ca... on n'applique pas de patchs
qu'on ne comprend pas.
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 ?
A cote de ca, en gros l'OS s'annonce aupres de l'acpi. Mais la seule strategie raisonnable, c'est de s'annoncer comme etant du windows, parce qu'en pratique, c'est le seul mode que les constructeurs ont debuggue.
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...
Au moins chez nous, on ne joue pas a ca... on n'applique pas de patchs qu'on ne comprend pas.
Thierry B.
--{ Vincent a plopé ceci: }--
Bon, d'un autre côté, la doc de l'ACPI a l'air d'être librement téléchargeable.
Pas par les constructeur de machines, il faut croire...
--
Il n'y a pas de gestion des dependance dans la Slack, elle n'est pas calamiteuse, elle n'existe pas. C'est bien ce que je te dis. Elle est calamiteuse parce qu'elle n'existe pas
--{ JKB, in fcol.debats }--
--{ Vincent a plopé ceci: }--
Bon, d'un autre côté, la doc de l'ACPI a l'air d'être librement
téléchargeable.
Pas par les constructeur de machines, il faut croire...
--
Il n'y a pas de gestion des dependance dans la Slack, elle n'est pas
calamiteuse, elle n'existe pas.
C'est bien ce que je te dis. Elle est calamiteuse parce qu'elle n'existe pas
Bon, d'un autre côté, la doc de l'ACPI a l'air d'être librement téléchargeable.
Pas par les constructeur de machines, il faut croire...
--
Il n'y a pas de gestion des dependance dans la Slack, elle n'est pas calamiteuse, elle n'existe pas. C'est bien ce que je te dis. Elle est calamiteuse parce qu'elle n'existe pas
--{ JKB, in fcol.debats }--
Vincent (ex Elendir)
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Lequel ? Celui que j'utilise sur ce portable utilise un HAL qui est de toute façon un objet binaire. Vous parlez du Open-HAL ?
Vincent
Il va falloir que je fouille dans les archives, mais là, _à
brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec
NDA
Lequel ? Celui que j'utilise sur ce portable utilise un HAL qui est de
toute façon un objet binaire. Vous parlez du Open-HAL ?
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Lequel ? Celui que j'utilise sur ce portable utilise un HAL qui est de toute façon un objet binaire. Vous parlez du Open-HAL ?
Vincent
espie
In article , Thierry Herbelot wrote:
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...
ouh ! c'est vil (et donc pas trop surprenant, venant d'un barbu sournois)
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Ca fait deja un exemple chez Free, on ne compte plus les exemples chez Nunux... typiquement, Dave Miller paye par Sun, par exemple.
In article <51nai5-g9u.ln1@tfh.herbelot.nom>,
Thierry Herbelot <thierry@herbelot.com> wrote:
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...
ouh ! c'est vil (et donc pas trop surprenant, venant d'un barbu sournois)
Il va falloir que je fouille dans les archives, mais là, _à
brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec
NDA
Ca fait deja un exemple chez Free, on ne compte plus les exemples chez
Nunux... typiquement, Dave Miller paye par Sun, par exemple.
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...
ouh ! c'est vil (et donc pas trop surprenant, venant d'un barbu sournois)
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Ca fait deja un exemple chez Free, on ne compte plus les exemples chez Nunux... typiquement, Dave Miller paye par Sun, par exemple.
Manuel Bouyer
Vincent wrote:
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 ?
Pas completement, mais il doit y avoir tout ce qu'il faut sur develooper.intel.com pour comprendre ce qu'il faut faire. Apres, qu'une machine en particulier ne se comporte pas comme c'est marque dans les docs ...
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Vincent <10.50@free.fr> wrote:
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 ?
Pas completement, mais il doit y avoir tout ce qu'il faut sur
develooper.intel.com pour comprendre ce qu'il faut faire.
Apres, qu'une machine en particulier ne se comporte pas comme c'est
marque dans les docs ...
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
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 ?
Pas completement, mais il doit y avoir tout ce qu'il faut sur develooper.intel.com pour comprendre ce qu'il faut faire. Apres, qu'une machine en particulier ne se comporte pas comme c'est marque dans les docs ...
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
espie
In article <g2uced$2n7s$, Manuel Bouyer wrote:
Vincent wrote:
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 ?
Pas completement, mais il doit y avoir tout ce qu'il faut sur develooper.intel.com pour comprendre ce qu'il faut faire. Apres, qu'une machine en particulier ne se comporte pas comme c'est marque dans les docs ...
Soyons mauvaise langue... qu'une machine en particulier se comporte comme c'est marque dans les docs, ca arrive parfois.
In article <g2uced$2n7s$1@biggoron.nerim.net>,
Manuel Bouyer <bouyer@nerim.net> wrote:
Vincent <10.50@free.fr> wrote:
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 ?
Pas completement, mais il doit y avoir tout ce qu'il faut sur
develooper.intel.com pour comprendre ce qu'il faut faire.
Apres, qu'une machine en particulier ne se comporte pas comme c'est
marque dans les docs ...
Soyons mauvaise langue... qu'une machine en particulier se comporte
comme c'est marque dans les docs, ca arrive parfois.
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 ?
Pas completement, mais il doit y avoir tout ce qu'il faut sur develooper.intel.com pour comprendre ce qu'il faut faire. Apres, qu'une machine en particulier ne se comporte pas comme c'est marque dans les docs ...
Soyons mauvaise langue... qu'une machine en particulier se comporte comme c'est marque dans les docs, ca arrive parfois.
Vincent (ex Elendir)
Soyons mauvaise langue... qu'une machine en particulier se comporte comme c'est marque dans les docs, ca arrive parfois.
Parfois, ça tombe en marche, c'est ça ?
Soyons mauvaise langue... qu'une machine en particulier se comporte
comme c'est marque dans les docs, ca arrive parfois.
Soyons mauvaise langue... qu'une machine en particulier se comporte comme c'est marque dans les docs, ca arrive parfois.
D'un autre côté pas un téléphone portable ne respecte les specsde l'ETSI à lalettre, et pourtant ça marche...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
espie
In article , Thierry Herbelot wrote:
Marc Espie wrote:
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Ca fait deja un exemple chez Free, on ne compte plus les exemples chez Nunux... typiquement, Dave Miller paye par Sun, par exemple.
amalgame, quand tu nous tiens : la fourberie du BSDien frappe encore, en insinuant que les fautes, que dis-je les crimes, commis par les suppôts de Linus ont contaminé aussi les développeurs de Libre/GratuitBSD
Honnetement, FreeBSD a adopte NDIS, et ils ont aussi un support pour les pilotes binaires nvidia. On n'est vraiment pas loin du commercial...
Attend que Miod passe par la, il doit etre plus au fait que moi des diverses malversations des commerciaux.
In article <fl1bi5-adv.ln1@tfh.herbelot.nom>,
Thierry Herbelot <thierry@herbelot.com> wrote:
Marc Espie wrote:
Il va falloir que je fouille dans les archives, mais là, _à
brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec
NDA
Ca fait deja un exemple chez Free, on ne compte plus les exemples chez
Nunux... typiquement, Dave Miller paye par Sun, par exemple.
amalgame, quand tu nous tiens : la fourberie du BSDien frappe encore, en
insinuant que les fautes, que dis-je les crimes, commis par les suppôts de
Linus ont contaminé aussi les développeurs de Libre/GratuitBSD
Honnetement, FreeBSD a adopte NDIS, et ils ont aussi un support pour les
pilotes binaires nvidia. On n'est vraiment pas loin du commercial...
Attend que Miod passe par la, il doit etre plus au fait que moi des diverses
malversations des commerciaux.
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Ca fait deja un exemple chez Free, on ne compte plus les exemples chez Nunux... typiquement, Dave Miller paye par Sun, par exemple.
amalgame, quand tu nous tiens : la fourberie du BSDien frappe encore, en insinuant que les fautes, que dis-je les crimes, commis par les suppôts de Linus ont contaminé aussi les développeurs de Libre/GratuitBSD
Honnetement, FreeBSD a adopte NDIS, et ils ont aussi un support pour les pilotes binaires nvidia. On n'est vraiment pas loin du commercial...
Attend que Miod passe par la, il doit etre plus au fait que moi des diverses malversations des commerciaux.
Patrick Lamaizière
Le Fri, 13 Jun 2008 19:23:00 +0200, Thierry Herbelot <------%------thierry------% a
Il va falloir que je fouille dans les archives, mais là, _à brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé avec NDA
Il me semble qu'il y a eu nve pour les chipset nvidia nforce. Remplacé par nfe.
Le Fri, 13 Jun 2008 19:23:00 +0200,
Thierry Herbelot <------%------thierry------%------@herbelot.com> a
Il va falloir que je fouille dans les archives, mais là, _à
brûle-pourpoint_, je ne vois "que" le driver ATH qui soit développé
avec NDA
Il me semble qu'il y a eu nve pour les chipset nvidia nforce. Remplacé
par nfe.
