Linuxien depuis quelques années, j'éprouve de plus en plus l'envie de
changer de système.
Les systèmes basés BSD me semblent être l'alternative la plus crédible à mes
yeux (non, non, je n'ai pas envie de retourner sous Windows).
Cependant, avant de me lancer dans l'aventure BSD, j'aimerais connaître la
liste des principales "distributions" BSD (c'est comme ça qu'on dit ?) et
leurs différences essentielles.
Un lien pourrait suffire, une explication serait au top (je n'ai pas besoin
de détails précis sur les différentes fonctionalités)
Pour information, bien que je sois assez à l'aise en ligne de commande j'ai
encore besoin d'une interface graphique pour certains de mes besoins
(multimedia, internet) et détail important, j'ai une carte video NVidia
(quadro).
Autres questions plus ou moins stupides/naïves en vrac :
- Peut on trouver une liste des matériels incompatibles ?
- Selon vous, quels sont les avantages évident des systèmes BSD sur Linux
(et l'inverse)
- Compile t-on son noyau sous BSD ?
- Quelqu'un a t-il une liste de sites à visiter (tutoriels d'installation,
conseils aux novices...) avant de franchir le pas ?
- J'en passe et des meilleures....
Dans l'attente de vos réponses endiablées, je vous souhaite une bonne
[ ] journée.
[ ] soirée.
[ ] nuit.
(cocher la mention correspondant à votre situation)
Merci d'avance et à bientôt sous BSD.
--
@+
Doug [Linux user #307925] - Slackware RuleZ ;-)
[Pourquoi t'es qui, qu'est ce que tu fais par où ?]
-- Pour me contacter enlever no-spam (2X) --
Je me suis un peu renseigné sur le HAL de NT et justement à l'origine cela devait permettre de porter le noyau, écrit en C, sur alpha, mips, ppc et i386. Je n'ai pas réussi à savoir pourquoi ça n'a pas abouti : HAL mal foutu, pas assez rentable ou tout simplement pas possible ?
Les premières versions étaient disponible pour ces architectures. C'est la stratégie commerciale de Microsoft qui a conduit à leur abandon. Les premières versions de NT n'ont pas eu de succès.
D'après Cyrille Szymanski:
Je me suis un peu renseigné sur le HAL de NT
et justement à l'origine cela
devait permettre de porter le noyau, écrit en C, sur alpha, mips, ppc et
i386.
Je n'ai pas réussi à savoir pourquoi ça n'a pas abouti : HAL mal
foutu, pas assez rentable ou tout simplement pas possible ?
Les premières versions étaient disponible pour ces architectures.
C'est la stratégie commerciale de Microsoft qui a conduit à leur abandon.
Les premières versions de NT n'ont pas eu de succès.
Je me suis un peu renseigné sur le HAL de NT et justement à l'origine cela devait permettre de porter le noyau, écrit en C, sur alpha, mips, ppc et i386. Je n'ai pas réussi à savoir pourquoi ça n'a pas abouti : HAL mal foutu, pas assez rentable ou tout simplement pas possible ?
Les premières versions étaient disponible pour ces architectures. C'est la stratégie commerciale de Microsoft qui a conduit à leur abandon. Les premières versions de NT n'ont pas eu de succès.
Xavier Maillard
On 8 Jun 2005, Cyrille Szymanski wrote:
Prends le C++, les templates ça fout bien la grouille au niveau de l'analyseur lexical pour ne citer que cet exemple, et pourtant on ne peut pas dire que ce langage soit un échec.
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais percé et qui ne percera jamais, c'est bien le C++. Quand on voit que les compilateurs actuels rament comme ce n'est pas permis pour entrevoir l'idée de suivre le standard...
En plus, j'entends de plus en plus de voix s'élever pour dire que le C++ est en chute libre (perte de vitesse). Le C++ est mort selon moi mais le java a connu la même période creuse pour rebondir quelques années plus tard.
Je ne le cache pas, je n'apprécie pas le C++ (tout juste arrive-je à tolérer le C) alors forcément je ne suis pas complètement objectif :)
Non, c'est trop facile de cracher sur tout ce qui passe parce que ce n'est pas parfait. C'est la mentalité des Français ça après tout.
Le Français ne crache pas, le Français est critique et râleur ;) C'est ce qui fait que tout le monde nous jalouse honteusement :)
Donc forcément, dans ce genre de contexte tu n'as pas forcément envie de suivre leur recommandantions ...
Ils font un gros effort de standardisation, et je me demande à quoi ressemblerait le Web s'ils n'étaient pas là.
Tout à fait d'accord mais d'un autre côté, sans le W3C, le standard serait Microsoft comme ce fut plus ou moins le cas il y a quelques années. Les choses changent et c'est plutôt bien. -- No e-patents, pas de brevets logiciels Pétition contre les brevets logiciels : http://petition.eurolinux.org
On 8 Jun 2005, Cyrille Szymanski wrote:
Prends le C++, les templates ça fout bien la grouille au niveau
de l'analyseur lexical pour ne citer que cet exemple, et
pourtant on ne peut pas dire que ce langage soit un échec.
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais
percé et qui ne percera jamais, c'est bien le C++. Quand on voit
que les compilateurs actuels rament comme ce n'est pas permis
pour entrevoir l'idée de suivre le standard...
En plus, j'entends de plus en plus de voix s'élever pour dire que
le C++ est en chute libre (perte de vitesse). Le C++ est mort
selon moi mais le java a connu la même période creuse pour
rebondir quelques années plus tard.
Je ne le cache pas, je n'apprécie pas le C++ (tout juste
arrive-je à tolérer le C) alors forcément je ne suis pas
complètement objectif :)
Non, c'est trop facile de cracher sur tout ce qui passe parce
que ce n'est pas parfait. C'est la mentalité des Français ça
après tout.
Le Français ne crache pas, le Français est critique et râleur ;)
C'est ce qui fait que tout le monde nous jalouse honteusement :)
Donc forcément, dans ce genre de contexte tu n'as pas
forcément envie de suivre leur recommandantions ...
Ils font un gros effort de standardisation, et je me demande à
quoi ressemblerait le Web s'ils n'étaient pas là.
Tout à fait d'accord mais d'un autre côté, sans le W3C, le
standard serait Microsoft comme ce fut plus ou moins le cas il y
a quelques années. Les choses changent et c'est plutôt bien.
--
No e-patents, pas de brevets logiciels
Pétition contre les brevets logiciels : http://petition.eurolinux.org
Prends le C++, les templates ça fout bien la grouille au niveau de l'analyseur lexical pour ne citer que cet exemple, et pourtant on ne peut pas dire que ce langage soit un échec.
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais percé et qui ne percera jamais, c'est bien le C++. Quand on voit que les compilateurs actuels rament comme ce n'est pas permis pour entrevoir l'idée de suivre le standard...
En plus, j'entends de plus en plus de voix s'élever pour dire que le C++ est en chute libre (perte de vitesse). Le C++ est mort selon moi mais le java a connu la même période creuse pour rebondir quelques années plus tard.
Je ne le cache pas, je n'apprécie pas le C++ (tout juste arrive-je à tolérer le C) alors forcément je ne suis pas complètement objectif :)
Non, c'est trop facile de cracher sur tout ce qui passe parce que ce n'est pas parfait. C'est la mentalité des Français ça après tout.
Le Français ne crache pas, le Français est critique et râleur ;) C'est ce qui fait que tout le monde nous jalouse honteusement :)
Donc forcément, dans ce genre de contexte tu n'as pas forcément envie de suivre leur recommandantions ...
Ils font un gros effort de standardisation, et je me demande à quoi ressemblerait le Web s'ils n'étaient pas là.
Tout à fait d'accord mais d'un autre côté, sans le W3C, le standard serait Microsoft comme ce fut plus ou moins le cas il y a quelques années. Les choses changent et c'est plutôt bien. -- No e-patents, pas de brevets logiciels Pétition contre les brevets logiciels : http://petition.eurolinux.org
talon
Xavier Maillard wrote:
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais percé et qui ne percera jamais, c'est bien le C++. Quand on voit que les compilateurs actuels rament comme ce n'est pas permis pour entrevoir l'idée de suivre le standard...
C'est toi qui es sérieux, là? Ne serait-ce que grace à Visual C++ le C++ est probablement le langage le plus utilisé, ne serait-ce que dans un usage plus proche du C que du C++. Que ce soit ou non une monstruosité est une autre question.
--
Michel TALON
Xavier Maillard <zedek@gnu-rox.org> wrote:
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais
percé et qui ne percera jamais, c'est bien le C++. Quand on voit
que les compilateurs actuels rament comme ce n'est pas permis
pour entrevoir l'idée de suivre le standard...
C'est toi qui es sérieux, là? Ne serait-ce que grace à Visual C++
le C++ est probablement le langage le plus utilisé, ne serait-ce que dans un
usage plus proche du C que du C++. Que ce soit ou non une monstruosité est une
autre question.
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais percé et qui ne percera jamais, c'est bien le C++. Quand on voit que les compilateurs actuels rament comme ce n'est pas permis pour entrevoir l'idée de suivre le standard...
C'est toi qui es sérieux, là? Ne serait-ce que grace à Visual C++ le C++ est probablement le langage le plus utilisé, ne serait-ce que dans un usage plus proche du C que du C++. Que ce soit ou non une monstruosité est une autre question.
--
Michel TALON
Marwan Burelle
In article <d88s4m$tl3$, Michel Talon wrote:
C'est toi qui es sérieux, là? Ne serait-ce que grace à Visual C++ le C++ est probablement le langage le plus utilisé, ne serait-ce que dans un usage plus proche du C que du C++. Que ce soit ou non une monstruosité est une autre question.
Non, grasse à Visual studio le langage le plus utilisé est Visual Basic ... ;)
Plus sérieusement, la quantité de developpement sur micro n'a pas encore ratrapé le paquet de trucs existant sur gros système, où là le cobol est roi ...
C'est surement en train de changer, mais ça reste une réalité, il existe plein d'informaticiens qui continuent à pondre des JCL, du Cobol et des requètes SQL. Au pire, on a tenté de leur faire utiliser Visual Edge Pacbase, mais bon ça pond du Cobol aussi ...
La différence, c'est que ces gens sont silencieux, que l'informatique n'est plus pour eux qu'une façon de se nourrir, le Cobol suprime toutes passions ...
C'est encore la démonstration qu'un langage pourri peut vivre et s'imposer ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
In article <d88s4m$tl3$1@asmodee.lpthe.jussieu.fr>, Michel Talon wrote:
C'est toi qui es sérieux, là? Ne serait-ce que grace à Visual C++
le C++ est probablement le langage le plus utilisé, ne serait-ce que dans un
usage plus proche du C que du C++. Que ce soit ou non une monstruosité est une
autre question.
Non, grasse à Visual studio le langage le plus utilisé est Visual
Basic ... ;)
Plus sérieusement, la quantité de developpement sur micro n'a pas
encore ratrapé le paquet de trucs existant sur gros système, où là le
cobol est roi ...
C'est surement en train de changer, mais ça reste une réalité, il
existe plein d'informaticiens qui continuent à pondre des JCL, du
Cobol et des requètes SQL. Au pire, on a tenté de leur faire utiliser
Visual Edge Pacbase, mais bon ça pond du Cobol aussi ...
La différence, c'est que ces gens sont silencieux, que l'informatique
n'est plus pour eux qu'une façon de se nourrir, le Cobol suprime
toutes passions ...
C'est encore la démonstration qu'un langage pourri peut vivre et
s'imposer ...
--
Burelle Marwan,
Equipe Bases de Donnees - LRI
http://www.cduce.org
(burelle@lri.fr | Marwan.Burelle@ens.fr)
C'est toi qui es sérieux, là? Ne serait-ce que grace à Visual C++ le C++ est probablement le langage le plus utilisé, ne serait-ce que dans un usage plus proche du C que du C++. Que ce soit ou non une monstruosité est une autre question.
Non, grasse à Visual studio le langage le plus utilisé est Visual Basic ... ;)
Plus sérieusement, la quantité de developpement sur micro n'a pas encore ratrapé le paquet de trucs existant sur gros système, où là le cobol est roi ...
C'est surement en train de changer, mais ça reste une réalité, il existe plein d'informaticiens qui continuent à pondre des JCL, du Cobol et des requètes SQL. Au pire, on a tenté de leur faire utiliser Visual Edge Pacbase, mais bon ça pond du Cobol aussi ...
La différence, c'est que ces gens sont silencieux, que l'informatique n'est plus pour eux qu'une façon de se nourrir, le Cobol suprime toutes passions ...
C'est encore la démonstration qu'un langage pourri peut vivre et s'imposer ...
-- Burelle Marwan, Equipe Bases de Donnees - LRI http://www.cduce.org ( | )
Cyrille Szymanski
Miod Vallat wrote in news:42a734b2$0$23346$:
NT sur alpha ne permettait pas à ses applications d'utiliser plus de 4GB de mémoire virtuelle, par exemple...
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche d'abstraction.
Des pages de manuel en section 9, et pas mal de commentaires dispersés dans le code. Par exemple, les interfaces bus_space(9) et bus_dma(9) sont assez proches entre les trois systèmes, et permettent de faire marcher n'importe quel chip moderne raisonnablement bien sur divers bus (obio, pci, sbus, vme) avec le moins possible de support bas niveau ; mais on trouve malheureusement toujours de temps à autre un ``#ifdef monarch'' dans du code supposé MI car l'interface n'est pas assez générique...
J'ai parcouru bus_space(9) sur NetBSD, c'est de la belle doc. "A Machine- Independent DMA Framework for NetBSD" a l'air prometteur aussi.
Globalement tu dirais que c'est une bonne interface (dans le sens, ok il lui manque certaines choses mais tout peut s'arranger) ou une mauvaise (dans le sens, non les choix initiaux de conception font qu'on va tomber dans une impasse) ?
Par contre dans ma précipitation je suis passé un peu vite sur le fait que les drivers offrent une interface au système d'exploitation et il faudrait aussi standardiser ça, et là pour le coup c'est loin d'être gagné.
En tout cas merci beaucoup pour cette discussion -- Cyrille Szymanski
Miod Vallat <miod@online.fr> wrote in
news:42a734b2$0$23346$636a15ce@news.free.fr:
NT sur alpha ne permettait pas à ses applications d'utiliser plus
de 4GB de mémoire virtuelle, par exemple...
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche
d'abstraction.
Des pages de manuel en section 9, et pas mal de commentaires dispersés
dans le code. Par exemple, les interfaces bus_space(9) et bus_dma(9)
sont assez proches entre les trois systèmes, et permettent de faire
marcher n'importe quel chip moderne raisonnablement bien sur divers
bus (obio, pci, sbus, vme) avec le moins possible de support bas
niveau ; mais on trouve malheureusement toujours de temps à autre un
``#ifdef monarch'' dans du code supposé MI car l'interface n'est pas
assez générique...
J'ai parcouru bus_space(9) sur NetBSD, c'est de la belle doc. "A Machine-
Independent DMA Framework for NetBSD" a l'air prometteur aussi.
Globalement tu dirais que c'est une bonne interface (dans le sens, ok il
lui manque certaines choses mais tout peut s'arranger) ou une mauvaise
(dans le sens, non les choix initiaux de conception font qu'on va tomber
dans une impasse) ?
Par contre dans ma précipitation je suis passé un peu vite sur le fait
que les drivers offrent une interface au système d'exploitation et il
faudrait aussi standardiser ça, et là pour le coup c'est loin d'être
gagné.
En tout cas merci beaucoup pour cette discussion
--
Cyrille Szymanski
NT sur alpha ne permettait pas à ses applications d'utiliser plus de 4GB de mémoire virtuelle, par exemple...
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche d'abstraction.
Des pages de manuel en section 9, et pas mal de commentaires dispersés dans le code. Par exemple, les interfaces bus_space(9) et bus_dma(9) sont assez proches entre les trois systèmes, et permettent de faire marcher n'importe quel chip moderne raisonnablement bien sur divers bus (obio, pci, sbus, vme) avec le moins possible de support bas niveau ; mais on trouve malheureusement toujours de temps à autre un ``#ifdef monarch'' dans du code supposé MI car l'interface n'est pas assez générique...
J'ai parcouru bus_space(9) sur NetBSD, c'est de la belle doc. "A Machine- Independent DMA Framework for NetBSD" a l'air prometteur aussi.
Globalement tu dirais que c'est une bonne interface (dans le sens, ok il lui manque certaines choses mais tout peut s'arranger) ou une mauvaise (dans le sens, non les choix initiaux de conception font qu'on va tomber dans une impasse) ?
Par contre dans ma précipitation je suis passé un peu vite sur le fait que les drivers offrent une interface au système d'exploitation et il faudrait aussi standardiser ça, et là pour le coup c'est loin d'être gagné.
En tout cas merci beaucoup pour cette discussion -- Cyrille Szymanski
Cyrille Szymanski
Xavier Maillard wrote in news: rox.org:
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais percé et qui ne percera jamais, c'est bien le C++. Quand on voit que les compilateurs actuels rament comme ce n'est pas permis pour entrevoir l'idée de suivre le standard...
Désolé d'avoir relancé ce bon vieux troll.
Je ne sais pas s'il existe une manière factuelle d'évaluer l'importace des différents langages, j'ai jamais rien vu de convaincant sur ce point.
Disons que le C++ est un des langages les plus connus - de nom hein, je suis pas certain que grand monde en saisisse ses nombreuses subtilités (on va appeler ça comme ça).
Je ne le cache pas, je n'apprécie pas le C++ (tout juste arrive-je à tolérer le C) alors forcément je ne suis pas complètement objectif :)
Je n'aime pas le C++ non plus, par contre le C me plaît beaucoup.
Tout à fait d'accord mais d'un autre côté, sans le W3C, le standard serait Microsoft comme ce fut plus ou moins le cas il y a quelques années. Les choses changent et c'est plutôt bien.
Je n'ai rien contre les standards Microsoft à part qu'ils sont trop souvent utilisés comme une arme commerciale.
-- Cyrille Szymanski for(n=0;b;n++) b&=b-1;
Xavier Maillard <zedek@gnu-rox.org> wrote in news:plop85k6l4zber.fsf@gnu-
rox.org:
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais
percé et qui ne percera jamais, c'est bien le C++. Quand on voit
que les compilateurs actuels rament comme ce n'est pas permis
pour entrevoir l'idée de suivre le standard...
Désolé d'avoir relancé ce bon vieux troll.
Je ne sais pas s'il existe une manière factuelle d'évaluer l'importace
des différents langages, j'ai jamais rien vu de convaincant sur ce point.
Disons que le C++ est un des langages les plus connus - de nom hein, je
suis pas certain que grand monde en saisisse ses nombreuses subtilités
(on va appeler ça comme ça).
Je ne le cache pas, je n'apprécie pas le C++ (tout juste
arrive-je à tolérer le C) alors forcément je ne suis pas
complètement objectif :)
Je n'aime pas le C++ non plus, par contre le C me plaît beaucoup.
Tout à fait d'accord mais d'un autre côté, sans le W3C, le
standard serait Microsoft comme ce fut plus ou moins le cas il y
a quelques années. Les choses changent et c'est plutôt bien.
Je n'ai rien contre les standards Microsoft à part qu'ils sont trop
souvent utilisés comme une arme commerciale.
Es-tu vraiment sérieux ? SI il y a bien un langage qui n'a jamais percé et qui ne percera jamais, c'est bien le C++. Quand on voit que les compilateurs actuels rament comme ce n'est pas permis pour entrevoir l'idée de suivre le standard...
Désolé d'avoir relancé ce bon vieux troll.
Je ne sais pas s'il existe une manière factuelle d'évaluer l'importace des différents langages, j'ai jamais rien vu de convaincant sur ce point.
Disons que le C++ est un des langages les plus connus - de nom hein, je suis pas certain que grand monde en saisisse ses nombreuses subtilités (on va appeler ça comme ça).
Je ne le cache pas, je n'apprécie pas le C++ (tout juste arrive-je à tolérer le C) alors forcément je ne suis pas complètement objectif :)
Je n'aime pas le C++ non plus, par contre le C me plaît beaucoup.
Tout à fait d'accord mais d'un autre côté, sans le W3C, le standard serait Microsoft comme ce fut plus ou moins le cas il y a quelques années. Les choses changent et c'est plutôt bien.
Je n'ai rien contre les standards Microsoft à part qu'ils sont trop souvent utilisés comme une arme commerciale.
-- Cyrille Szymanski for(n=0;b;n++) b&=b-1;
Miod Vallat
NT sur alpha ne permettait pas à ses applications d'utiliser plus de 4GB de mémoire virtuelle, par exemple...
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche d'abstraction.
De l'eau à mon moulin ! Cette restriction est tout à fait compréhensible car elle permet d'être sûr que du code raisonnablement propre compilera *ET FONCTIONNERA* sur toutes les plate-formes supportées par Windows NT.
Mais en pratique, on s'aliène sérieusement les gens qui ont besoin de mémoire (pour du calcul scientifique, par exemple).
Globalement tu dirais que c'est une bonne interface (dans le sens, ok il lui manque certaines choses mais tout peut s'arranger) ou une mauvaise (dans le sens, non les choix initiaux de conception font qu'on va tomber dans une impasse) ?
J'estime que bus_space(9) est un gigantesque pied de nez à la lune, mais dans *certaines* situations, c'est bien pratique. Par contre, bus_dma(9) me paraît une excellente idée - d'ailleurs s'il y a eu des divergences sur bus_space entre les principaux BSD, il n'y en a pour ainsi dire pas eu pour bus_dma.
Cependant, la généricité de bus_dma est parfois un problème. Prenons par exemple le cas des systèmes à base de processeurs POWER ou PowerPC. Pour certains modèles bas de gamme ou anciens, le processeur ne garantit pas la cohérence des caches (même en activant le snooping sur les adjuvants qui en sont capables). C'est pourquoi bus_dma fournit une fonction, bus_dmamap_sync(), pour arrondir les angles.
Maintenant, imagine que tu roules BSD sur un McIntosh à base de processeur PowerPC et OpenFirmware v3 ou mieux. Ceci représente toutes les machines Apple depuis l'iMac originel jusqu'aux derniers modèles à base de PowerPC, avant les modèles basés sur du x86. Toutes ces machines ont des processeurs qui garantissent la cohérence des caches, même en multiprocesseur (quel bonheur), donc bus_dmamap_sync() peut devenir un bête
#define bus_dmamap_sync() do { /* nothing */ } while (0)
Oui, mais voilà, on veut aussi supporter les premiers PowerMac. Ah mais alors, il est nécessaire que bus_dmamap_sync() soit une fonction, quitte à ce qu'elle ne fasse rien si le processeur a «les bonnes propriétés» (TM).
Donc nous voilà avec : - des appels à une routine (et hop, 20 octets par appel !) - une routine qui prend du temps (mais pour rien pour 99% du parc !)
Et derrière, on s'étonne que *BSD sur mac, c'est pas ça au niveau performances...
Ah oui mais, mon bon monsieur, ma bonne dame, il faut savoir ce que l'on veut...
NT sur alpha ne permettait pas à ses applications d'utiliser plus
de 4GB de mémoire virtuelle, par exemple...
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche
d'abstraction.
De l'eau à mon moulin ! Cette restriction est tout à fait compréhensible
car elle permet d'être sûr que du code raisonnablement propre compilera
*ET FONCTIONNERA* sur toutes les plate-formes supportées par Windows NT.
Mais en pratique, on s'aliène sérieusement les gens qui ont besoin de
mémoire (pour du calcul scientifique, par exemple).
Globalement tu dirais que c'est une bonne interface (dans le sens, ok il
lui manque certaines choses mais tout peut s'arranger) ou une mauvaise
(dans le sens, non les choix initiaux de conception font qu'on va tomber
dans une impasse) ?
J'estime que bus_space(9) est un gigantesque pied de nez à la lune, mais
dans *certaines* situations, c'est bien pratique. Par contre, bus_dma(9)
me paraît une excellente idée - d'ailleurs s'il y a eu des divergences
sur bus_space entre les principaux BSD, il n'y en a pour ainsi dire pas
eu pour bus_dma.
Cependant, la généricité de bus_dma est parfois un problème. Prenons par
exemple le cas des systèmes à base de processeurs POWER ou PowerPC. Pour
certains modèles bas de gamme ou anciens, le processeur ne garantit pas
la cohérence des caches (même en activant le snooping sur les adjuvants
qui en sont capables). C'est pourquoi bus_dma fournit une fonction,
bus_dmamap_sync(), pour arrondir les angles.
Maintenant, imagine que tu roules BSD sur un McIntosh à base de
processeur PowerPC et OpenFirmware v3 ou mieux. Ceci représente toutes
les machines Apple depuis l'iMac originel jusqu'aux derniers modèles à
base de PowerPC, avant les modèles basés sur du x86. Toutes ces
machines ont des processeurs qui garantissent la cohérence des caches,
même en multiprocesseur (quel bonheur), donc bus_dmamap_sync() peut
devenir un bête
#define bus_dmamap_sync() do { /* nothing */ } while (0)
Oui, mais voilà, on veut aussi supporter les premiers PowerMac. Ah mais
alors, il est nécessaire que bus_dmamap_sync() soit une fonction, quitte
à ce qu'elle ne fasse rien si le processeur a «les bonnes propriétés»
(TM).
Donc nous voilà avec :
- des appels à une routine (et hop, 20 octets par appel !)
- une routine qui prend du temps (mais pour rien pour 99% du parc !)
Et derrière, on s'étonne que *BSD sur mac, c'est pas ça au niveau
performances...
Ah oui mais, mon bon monsieur, ma bonne dame, il faut savoir ce que l'on
veut...
NT sur alpha ne permettait pas à ses applications d'utiliser plus de 4GB de mémoire virtuelle, par exemple...
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche d'abstraction.
De l'eau à mon moulin ! Cette restriction est tout à fait compréhensible car elle permet d'être sûr que du code raisonnablement propre compilera *ET FONCTIONNERA* sur toutes les plate-formes supportées par Windows NT.
Mais en pratique, on s'aliène sérieusement les gens qui ont besoin de mémoire (pour du calcul scientifique, par exemple).
Globalement tu dirais que c'est une bonne interface (dans le sens, ok il lui manque certaines choses mais tout peut s'arranger) ou une mauvaise (dans le sens, non les choix initiaux de conception font qu'on va tomber dans une impasse) ?
J'estime que bus_space(9) est un gigantesque pied de nez à la lune, mais dans *certaines* situations, c'est bien pratique. Par contre, bus_dma(9) me paraît une excellente idée - d'ailleurs s'il y a eu des divergences sur bus_space entre les principaux BSD, il n'y en a pour ainsi dire pas eu pour bus_dma.
Cependant, la généricité de bus_dma est parfois un problème. Prenons par exemple le cas des systèmes à base de processeurs POWER ou PowerPC. Pour certains modèles bas de gamme ou anciens, le processeur ne garantit pas la cohérence des caches (même en activant le snooping sur les adjuvants qui en sont capables). C'est pourquoi bus_dma fournit une fonction, bus_dmamap_sync(), pour arrondir les angles.
Maintenant, imagine que tu roules BSD sur un McIntosh à base de processeur PowerPC et OpenFirmware v3 ou mieux. Ceci représente toutes les machines Apple depuis l'iMac originel jusqu'aux derniers modèles à base de PowerPC, avant les modèles basés sur du x86. Toutes ces machines ont des processeurs qui garantissent la cohérence des caches, même en multiprocesseur (quel bonheur), donc bus_dmamap_sync() peut devenir un bête
#define bus_dmamap_sync() do { /* nothing */ } while (0)
Oui, mais voilà, on veut aussi supporter les premiers PowerMac. Ah mais alors, il est nécessaire que bus_dmamap_sync() soit une fonction, quitte à ce qu'elle ne fasse rien si le processeur a «les bonnes propriétés» (TM).
Donc nous voilà avec : - des appels à une routine (et hop, 20 octets par appel !) - une routine qui prend du temps (mais pour rien pour 99% du parc !)
Et derrière, on s'étonne que *BSD sur mac, c'est pas ça au niveau performances...
Ah oui mais, mon bon monsieur, ma bonne dame, il faut savoir ce que l'on veut...
Manuel Bouyer
Miod Vallat wrote:
[...] Cependant, la généricité de bus_dma est parfois un problème. Prenons par exemple le cas des systèmes à base de processeurs POWER ou PowerPC. Pour certains modèles bas de gamme ou anciens, le processeur ne garantit pas la cohérence des caches (même en activant le snooping sur les adjuvants qui en sont capables). C'est pourquoi bus_dma fournit une fonction, bus_dmamap_sync(), pour arrondir les angles.
Maintenant, imagine que tu roules BSD sur un McIntosh à base de processeur PowerPC et OpenFirmware v3 ou mieux. Ceci représente toutes les machines Apple depuis l'iMac originel jusqu'aux derniers modèles à base de PowerPC, avant les modèles basés sur du x86. Toutes ces machines ont des processeurs qui garantissent la cohérence des caches, même en multiprocesseur (quel bonheur), donc bus_dmamap_sync() peut devenir un bête
#define bus_dmamap_sync() do { /* nothing */ } while (0)
Oui, mais voilà, on veut aussi supporter les premiers PowerMac. Ah mais alors, il est nécessaire que bus_dmamap_sync() soit une fonction, quitte à ce qu'elle ne fasse rien si le processeur a «les bonnes propriétés» (TM).
Donc nous voilà avec : - des appels à une routine (et hop, 20 octets par appel !) - une routine qui prend du temps (mais pour rien pour 99% du parc !)
Et derrière, on s'étonne que *BSD sur mac, c'est pas ça au niveau performances...
Note que ce type de probleme est facile a resoudre. Par exemple dans le cas preci de la coherence de cache, ca n'affecte pas que bus_dmamap_sync() et donc il y a d'autre partie du code (y compris du code MD) qui aura une fonction la ou un #define aurrait suffit pour un type de processeur donne. Maintenant, comme il y a une option correspondant a chaque type de processeur, on peut faire des #ifdef correspindant dans le code. Si plusieur types de CPU sont supportes par le kernel bus_dmamap_sync() est un appel de fonction, si un seul bus_dmamap_sync() est une macro.
Il y a deja d'autre parties du kernel qui sont comme ca: x86 (beaucoup de code, en particulier dans locore.S, dans un kernel qui ne supporte qu'une seule classe de processeur), sparc (des fonctions de pmap sont des pointeurs de fonctions si c'est un kernel GENERIC, des #define si c'est un kernel qui supporte seulement SUN4/4C ou SUN4M/4D).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Miod Vallat <miod@online.fr> wrote:
[...]
Cependant, la généricité de bus_dma est parfois un problème. Prenons par
exemple le cas des systèmes à base de processeurs POWER ou PowerPC. Pour
certains modèles bas de gamme ou anciens, le processeur ne garantit pas
la cohérence des caches (même en activant le snooping sur les adjuvants
qui en sont capables). C'est pourquoi bus_dma fournit une fonction,
bus_dmamap_sync(), pour arrondir les angles.
Maintenant, imagine que tu roules BSD sur un McIntosh à base de
processeur PowerPC et OpenFirmware v3 ou mieux. Ceci représente toutes
les machines Apple depuis l'iMac originel jusqu'aux derniers modèles à
base de PowerPC, avant les modèles basés sur du x86. Toutes ces
machines ont des processeurs qui garantissent la cohérence des caches,
même en multiprocesseur (quel bonheur), donc bus_dmamap_sync() peut
devenir un bête
#define bus_dmamap_sync() do { /* nothing */ } while (0)
Oui, mais voilà, on veut aussi supporter les premiers PowerMac. Ah mais
alors, il est nécessaire que bus_dmamap_sync() soit une fonction, quitte
à ce qu'elle ne fasse rien si le processeur a «les bonnes propriétés»
(TM).
Donc nous voilà avec :
- des appels à une routine (et hop, 20 octets par appel !)
- une routine qui prend du temps (mais pour rien pour 99% du parc !)
Et derrière, on s'étonne que *BSD sur mac, c'est pas ça au niveau
performances...
Note que ce type de probleme est facile a resoudre. Par exemple dans le
cas preci de la coherence de cache, ca n'affecte pas que bus_dmamap_sync()
et donc il y a d'autre partie du code (y compris du code MD) qui aura
une fonction la ou un #define aurrait suffit pour un type de processeur
donne. Maintenant, comme il y a une option correspondant a chaque type
de processeur, on peut faire des #ifdef correspindant dans le code.
Si plusieur types de CPU sont supportes par le kernel bus_dmamap_sync()
est un appel de fonction, si un seul bus_dmamap_sync() est une macro.
Il y a deja d'autre parties du kernel qui sont comme ca: x86 (beaucoup de code,
en particulier dans locore.S, dans un kernel qui ne supporte qu'une seule
classe de processeur), sparc (des fonctions de pmap sont des pointeurs de
fonctions si c'est un kernel GENERIC, des #define si c'est un kernel qui
supporte seulement SUN4/4C ou SUN4M/4D).
--
Manuel Bouyer <bouyer@nerim.net>
NetBSD: 26 ans d'experience feront toujours la difference
--
[...] Cependant, la généricité de bus_dma est parfois un problème. Prenons par exemple le cas des systèmes à base de processeurs POWER ou PowerPC. Pour certains modèles bas de gamme ou anciens, le processeur ne garantit pas la cohérence des caches (même en activant le snooping sur les adjuvants qui en sont capables). C'est pourquoi bus_dma fournit une fonction, bus_dmamap_sync(), pour arrondir les angles.
Maintenant, imagine que tu roules BSD sur un McIntosh à base de processeur PowerPC et OpenFirmware v3 ou mieux. Ceci représente toutes les machines Apple depuis l'iMac originel jusqu'aux derniers modèles à base de PowerPC, avant les modèles basés sur du x86. Toutes ces machines ont des processeurs qui garantissent la cohérence des caches, même en multiprocesseur (quel bonheur), donc bus_dmamap_sync() peut devenir un bête
#define bus_dmamap_sync() do { /* nothing */ } while (0)
Oui, mais voilà, on veut aussi supporter les premiers PowerMac. Ah mais alors, il est nécessaire que bus_dmamap_sync() soit une fonction, quitte à ce qu'elle ne fasse rien si le processeur a «les bonnes propriétés» (TM).
Donc nous voilà avec : - des appels à une routine (et hop, 20 octets par appel !) - une routine qui prend du temps (mais pour rien pour 99% du parc !)
Et derrière, on s'étonne que *BSD sur mac, c'est pas ça au niveau performances...
Note que ce type de probleme est facile a resoudre. Par exemple dans le cas preci de la coherence de cache, ca n'affecte pas que bus_dmamap_sync() et donc il y a d'autre partie du code (y compris du code MD) qui aura une fonction la ou un #define aurrait suffit pour un type de processeur donne. Maintenant, comme il y a une option correspondant a chaque type de processeur, on peut faire des #ifdef correspindant dans le code. Si plusieur types de CPU sont supportes par le kernel bus_dmamap_sync() est un appel de fonction, si un seul bus_dmamap_sync() est une macro.
Il y a deja d'autre parties du kernel qui sont comme ca: x86 (beaucoup de code, en particulier dans locore.S, dans un kernel qui ne supporte qu'une seule classe de processeur), sparc (des fonctions de pmap sont des pointeurs de fonctions si c'est un kernel GENERIC, des #define si c'est un kernel qui supporte seulement SUN4/4C ou SUN4M/4D).
-- Manuel Bouyer NetBSD: 26 ans d'experience feront toujours la difference --
Eric Masson
Cyrille Szymanski writes:
'Lut,
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche d'abstraction.
Ben, c'est typiquement du MS ça, les 640 KB suffisants pour tout le monde en sont un bel exemple.
Amha, Dave Cutler, le papa de NT, avait du penser à ce genre de choses vu que VMS tourne en 64 bits sans aucun problème.
Les abstractions si elles sont bien pensées peuvent être quelque chose de vraiment profitable, les midrange ibm type as400/iSeries ont depuis toujours un système qui abstrait complètement le hard, ce qui a permis des changements majeurs d'architecture sans nécessiter de modification du userland (passage cisc 48 bits à Power 64 bits), et il sera possible de passer à la prochaine génération de Power 128 bits de façon transparente.
La seule chose que voit un programmeur sur iSeries est une machine virtuelle dont les apis sont étendues de façon régulière au fur et à mesure de la sortie de nouvelles versions du système, rien de plus bas niveau n'est accessible
Éric Masson
-- Est-ce un virus ? Je n'arrive pas à les enlever sauf ce matin où ils avaient tous disparus. On a eu une coupure de courant et les fichiers fantômes sont revenus. Aidez-nous -+- in : GNU - La nuit des neuneus vivants qu'on voudrait morts -+-
Cyrille Szymanski <cns@cns2.invalid> writes:
'Lut,
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche
d'abstraction.
Ben, c'est typiquement du MS ça, les 640 KB suffisants pour tout le
monde en sont un bel exemple.
Amha, Dave Cutler, le papa de NT, avait du penser à ce genre de choses
vu que VMS tourne en 64 bits sans aucun problème.
Les abstractions si elles sont bien pensées peuvent être quelque chose
de vraiment profitable, les midrange ibm type as400/iSeries ont depuis
toujours un système qui abstrait complètement le hard, ce qui a permis
des changements majeurs d'architecture sans nécessiter de modification
du userland (passage cisc 48 bits à Power 64 bits), et il sera possible
de passer à la prochaine génération de Power 128 bits de façon
transparente.
La seule chose que voit un programmeur sur iSeries est une machine
virtuelle dont les apis sont étendues de façon régulière au fur et à
mesure de la sortie de nouvelles versions du système, rien de plus bas
niveau n'est accessible
Éric Masson
--
Est-ce un virus ? Je n'arrive pas à les enlever sauf ce matin où ils
avaient tous disparus. On a eu une coupure de courant et les fichiers
fantômes sont revenus. Aidez-nous
-+- in : GNU - La nuit des neuneus vivants qu'on voudrait morts -+-
Oui c'est ce genre d'amputation qui a vite fait de tuer une couche d'abstraction.
Ben, c'est typiquement du MS ça, les 640 KB suffisants pour tout le monde en sont un bel exemple.
Amha, Dave Cutler, le papa de NT, avait du penser à ce genre de choses vu que VMS tourne en 64 bits sans aucun problème.
Les abstractions si elles sont bien pensées peuvent être quelque chose de vraiment profitable, les midrange ibm type as400/iSeries ont depuis toujours un système qui abstrait complètement le hard, ce qui a permis des changements majeurs d'architecture sans nécessiter de modification du userland (passage cisc 48 bits à Power 64 bits), et il sera possible de passer à la prochaine génération de Power 128 bits de façon transparente.
La seule chose que voit un programmeur sur iSeries est une machine virtuelle dont les apis sont étendues de façon régulière au fur et à mesure de la sortie de nouvelles versions du système, rien de plus bas niveau n'est accessible
Éric Masson
-- Est-ce un virus ? Je n'arrive pas à les enlever sauf ce matin où ils avaient tous disparus. On a eu une coupure de courant et les fichiers fantômes sont revenus. Aidez-nous -+- in : GNU - La nuit des neuneus vivants qu'on voudrait morts -+-
jl
Bonsoir à toutes, tous,
bonsoir
Un lien pourrait suffire,
voici un lien que j'ai trouvé il y a quelque temps : il y a une doc netbsd en français. http://www.bsdbooks.net/
Merci d'avance et à bientôt sous BSD.
de rien. Jean Luc
-- pour me répondre : sans antispam
Bonsoir à toutes, tous,
bonsoir
Un lien pourrait suffire,
voici un lien que j'ai trouvé il y a quelque temps : il y a une doc netbsd
en français. http://www.bsdbooks.net/
Merci d'avance et à bientôt sous BSD.
de rien. Jean Luc
--
pour me répondre : antispamjean-luc.ragot@wanadoo.fr sans antispam
