Ca aurait été sympa de faire un petit topo sur jnode et sur ce que ça apporte et ce qu'ils comptent en faire.
Sinon j'ai essayé le live cd dans qemu, mais ca plante.
Ils ont pas prévu une version user-mode qui ce lance dans une jvm java classique ? Ca pourrait sympa pour testé (et même pour faire du dev hors driver).
Au passage ca pourrait etre marrant de le faire tourner dans jpc [1] : faire tourner un OS java pour x86 dans un simulateur x86 en java :)
Le monde du logiciel libre se préoccupe surtout de la compatibilité au niveau source (API) et pas au niveau binaire (ABI). Seuls les grands groupes voulant distribuer des binaires sans le code source correspondant ont un intérêt crucial en l'existence d'une norme de compatibilité telle que LSB.
He ben linux n'est pas prêt de devenir grand publique alors :
james veux essayer le nouveau jeu libre qui viens de sortir. Pas de chance, pour le faire marcher sur sa distro il faut le recompiler. Apres quelques heures a se battre pour faire compiler le bousin, il redémarre sous windows et fait marché la version windows du jeu en quelques minutes
delopman a fait une petite appli sympa (un jeux a la con ou un petit utilitaire) et voudrait la partager avec tout le monde. Il a soit le choix de fournir que les sources, mais c'est pas tres convivial. Il peut aussi faire un paquet pour chaque distro, mais c'est pas cool pour lui.
Une autre parade c'est de garder les données sensible le moins de temps possible en RAM.
On peut aussi imaginer une fonction de verouillage du pc qui stocke la RAM dans un swap crypté et l'efface(en fait c'est un suspend to disk) qui est fait avant de quitter le PC ou au bout d'un timeout.
Il y a de la doc qui explique toute l'infrastructure du noyau ?
Oui il y a un make pdfdocs; plein de bouquins qui explique l'API de linux (http://lwn.net/Kernel/LDD3/ par exemple), son archi, ...; des articles dans les magazines spécialisé.
Je dis pas que la doc ne sert a rien, mais pour pouvoir en ecrire il faut du monde
Pas forcement, ca fait aussi parti des méthodes de dev : je rajoute une nouvelle interface, je mets des commentaires doxygen, ou je la décrits dans un README.
que ca ce reduit a une trentaine de personnes
Ben c'est sur que quand le projet detenu par peu de personne ca n'encourage pas à la doc (vu qu'ils connaissent tous tres bien le code), par contre à grande echelle ca ne passe pas.
Je pense pas que developer un driver soit si complique que ca, il suffit juste d'etre assez interesse pour devenir passione.
Tu te basses sur quoi pour dire ça ? ta boule de cristal ?
T'as au moins essayer de regarder un peu comment fonctionne la chose ?
PS : je connais pas gnome, mais je suis presque sur que l'API des différents bibliothèques importante sont documenté.
Je suppose que LLVM s'est fait un mode GCC dans lequel l'assembleur cible est le bytecode LLVM. Bien évidemment, il profite des optims du processus de compilation de GCC.
Ha, dans ce cas ça fait un truc quand même assez tordu :
- gcc converti le langage dans sa representation interne.
- Il fait des optimisation dessus (générique et propre à la cible). Dans notre cas c'est quoi la cible LLVM ou l'archi finale ?
- Ensuite cette representation serait converti en bytecode LLVM.
- Ce bytecode serait ensuite retransformé par LLVM.
- Puis on générerait enfin le code assembleur.
Bravo pour cet article très complet sur l'évolution du driver nouveau.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
A la lecture de la news, j'ai quelques point que je ne comprend pas.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1] Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
Ben si c'est ce que fait RT-linux & co.
L'intérêt c'est que l'OS RT fait tout ce qui est critique (stack GSM, ...) et on délégue au Linux ce qu'il l'est moins (multimedia, GUI, réseau, ...) et que l'OS RT ne gére pas d'origine.
Ben le francais n'est pas bien supporté : http://www.languagetool.org/download/README.txt
LanguageTool, a language style checker for English, German, Polish,
and Dutch with initial support for Spanish, French, and Italian
Et puis "sont élue ai parti" aboutit après correction à "Son élue ait parti"... De même "Son élue est parti" est considéré valide.
Toutefois, pour bénéficier de la correction orthographique, il fallait jusqu'à présent installer soi-même le dictionnaire français.
Sous debian, ca a toujours fait automatiquement...
Et même sur seamonkey...
Je me suis amusé, sur du code C à jouer à intervertir certaines instructions commutatives dans des boucles critiques (merci gcov) pour mutualiser les read/write.
Si tu as utiliser gcov, tu as donc fait des optimisation au runtime, chose que le compilo ne sait pas faire.
Par contre ça pourrait être fait par le processeur ou une machine virtuelle.
De plus le C est très complexe à optimiser (les informations de ce que faire le programmeur sont très pauvre). Du coût la plupart du temps l'optimisation d'un code C reflète son codage Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable
d'ailleurs un code C "optimiser" pour X86 peut être une grosse bousse sur une autre archi.
# ...
Posté par M . En réponse à la dépêche JNode version 0.2.6. Évalué à 3.
Sinon j'ai essayé le live cd dans qemu, mais ca plante.
Ils ont pas prévu une version user-mode qui ce lance dans une jvm java classique ? Ca pourrait sympa pour testé (et même pour faire du dev hors driver).
Au passage ca pourrait etre marrant de le faire tourner dans jpc [1] : faire tourner un OS java pour x86 dans un simulateur x86 en java :)
[1] (http://www-jpc.physics.ox.ac.uk/index.html)
# Compat binaire
Posté par M . En réponse à la dépêche Linux Standard Base 3.2. Évalué à 5.
He ben linux n'est pas prêt de devenir grand publique alors :
james veux essayer le nouveau jeu libre qui viens de sortir. Pas de chance, pour le faire marcher sur sa distro il faut le recompiler. Apres quelques heures a se battre pour faire compiler le bousin, il redémarre sous windows et fait marché la version windows du jeu en quelques minutes
delopman a fait une petite appli sympa (un jeux a la con ou un petit utilitaire) et voudrait la partager avec tout le monde. Il a soit le choix de fournir que les sources, mais c'est pas tres convivial. Il peut aussi faire un paquet pour chaque distro, mais c'est pas cool pour lui.
[...]
[^] # Re: La liste des critiques est incomplete
Posté par M . En réponse à la dépêche Linux Standard Base 3.2. Évalué à 4.
Au passage le format tar est defini dans posix, sa serait bete de le jeter...
[^] # Re: Parade
Posté par M . En réponse au journal Comment voler facilement des données chiffrées. Évalué à 3.
On peut aussi imaginer une fonction de verouillage du pc qui stocke la RAM dans un swap crypté et l'efface(en fait c'est un suspend to disk) qui est fait avant de quitter le PC ou au bout d'un timeout.
[^] # Re: l'interret ?
Posté par M . En réponse au journal Comment voler facilement des données chiffrées. Évalué à 2.
Tu oublis le bios qui remet la RAM à 0...
C'est d'ailleurs ce qui empeche de recupérer des données d'un kernel panic. Par contre la RAM video n'est pas remise à 0.
[^] # Re: Fichtre, ça va vite
Posté par M . En réponse au journal AMD libère un guide programmation 3D des R5xx. Évalué à 4.
Oui il y a un make pdfdocs; plein de bouquins qui explique l'API de linux (http://lwn.net/Kernel/LDD3/ par exemple), son archi, ...; des articles dans les magazines spécialisé.
Je dis pas que la doc ne sert a rien, mais pour pouvoir en ecrire il faut du monde
Pas forcement, ca fait aussi parti des méthodes de dev : je rajoute une nouvelle interface, je mets des commentaires doxygen, ou je la décrits dans un README.
que ca ce reduit a une trentaine de personnes
Ben c'est sur que quand le projet detenu par peu de personne ca n'encourage pas à la doc (vu qu'ils connaissent tous tres bien le code), par contre à grande echelle ca ne passe pas.
Je pense pas que developer un driver soit si complique que ca, il suffit juste d'etre assez interesse pour devenir passione.
Tu te basses sur quoi pour dire ça ? ta boule de cristal ?
T'as au moins essayer de regarder un peu comment fonctionne la chose ?
PS : je connais pas gnome, mais je suis presque sur que l'API des différents bibliothèques importante sont documenté.
[^] # Re: Fichtre, ça va vite
Posté par M . En réponse au journal AMD libère un guide programmation 3D des R5xx. Évalué à 1.
# virtualisation
Posté par M . En réponse au journal JNode l'OS en Java. Évalué à 4.
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 3.
Et je pari que comme par hasard, le code est friand d'optimisation JIT...
[^] # Re: questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
Ha, dans ce cas ça fait un truc quand même assez tordu :
- gcc converti le langage dans sa representation interne.
- Il fait des optimisation dessus (générique et propre à la cible). Dans notre cas c'est quoi la cible LLVM ou l'archi finale ?
- Ensuite cette representation serait converti en bytecode LLVM.
- Ce bytecode serait ensuite retransformé par LLVM.
- Puis on générerait enfin le code assembleur.
Et comment il vont faire avec clang ?
[^] # Re: questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
llvm-gcc 4.2 ...
Oui mais à terme ils comptent abandonner gcc ? Non ?
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 3.
Ben propose tes patchs a gcc.
Sur cible ARM, gcc se prend une grande claque par rapport à RVCT .
Qui est le compilo de ARM et qui ne gère que ARM.
De plus le passage gcc3.x à gcc 4.x à quand même améliorer les choses en taille et vitesse.
PS : pour llvm, regarde le README arm pour juger l'état
# bravo ... mais regret
Posté par M . En réponse à la dépêche Un point sur le projet Nouveau. Évalué à 6.
J'y ai participé occasionnellement et ce que je regrette c'est que l'on ai pas eu un support de la 3D très basique avec dri.
Pas un truc de la mort qui utilise toutes les fonctionnalité du hardware, mais un truc tout pourri qui soit un peu l'équivalent du support des cartes intel i810. [1] Si je veux un support 3D performant, je peux installer les drivers proprio qui marche pas trop mal.
Sur certaines cartes pour avoir un support correct de la gestion de plusieurs FIFO il a fallu presque 1 an.
La gestion de plusieurs FIFO est surtout intéressant pour la 3D (X en utilise une, le drm une autre (mais pour le moment je crois quel ne sert pas à grand chose)).
Le reverse engineering des commandes 3D, pour les cartes assez ancienne, est assez complet depuis quelque temps (même s'il reste surement certains pb qui seront découvert lors de leur utilisation). La gestion des textures à été enrichie lors de l'implémentation des versions accélérées d'EXA.
Une première implémentation mesa/dri [2] est assez ancienne (c'est celle ci qui a servit par exemple au LCA 2007 il y a 1 an). Sur les NV10, glxgears marchotte depuis presque 6 mois.
Tout ceci aurait pu laisser supposer un support basique de la 3D assez vite, mais gallium 3D est apparu.
Or pour les possesseurs de vielle carte (j'ai une NV17), on peut espérer maintenant un support 3D qu'à très long terme : il faut attendre que gallium 3D se stabilise, que la couche de support des cartes anciennes soit rajouté.
Or à ce moment là je crois que je n'utiliserais plus cette carte : elle sera soit morte (le ventillo à déjà cramé), soit je l'aurais remplacé par une autre carte (par exemple les nouvelles ATI avec pilote libre).
Je souhaite longue vie au projet nouveau et j'espère qu'il ne se terminera pas comme nvtv (appli pour faire marcher la sortie tv sous Linux) ou rivatv (driver pour faire marcher les tuner tv sous Linux) qui sont tous les 2 morts.
[1] qui permet tout de même de jouer à neverball, tuxracer, xmoto.
[2] au passage dri est très mal documenté...
# questions
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 6.
J'avais cru comprendre que LLVM transformait un code intermédiaire en assembleur.
Un frontend (gcc, clang) se chargeant de convertir le langage source utilisé dans ce langage intermédiaire.
Or dans ce cas, comment un changement du frontend améliore les performance [1]. Il génère un code intermédiaire plus détaillé ?
On nous parle de type "long double" supporté par LLVM, mais c'est pas plutôt le boulot du frontend de supporter les types du language qu'il parse ? Après lecture des release note, la modif est bien dans llvm-gcc.
On nous parle pas du tout de bibliothèque rattaché au langage.
Par exemple quelle libc llvm-gcc/clang supporte ?
Ou sera l'équivalent de libgcc (qui par exemple implémente le support des flottants en soft pour les archi qui ne l'ont pas) ?
PS :
Un inconvénient à LLVM est qu'il n'est pas bootstrapable facilement, c'est à dire qu'il aura toujours besoin que le système de destination ai déjà un compilo c++.
[1]
Le frontal utilisé passe de GCC 4.0 à GCC 4.2 afin d'améliorer les performances.
[^] # Re: Performances ?
Posté par M . En réponse à la dépêche LLVM 2.2 : Un concurrent pour GCC ?. Évalué à 2.
[^] # Re: point de départ
Posté par M . En réponse au message Achat clé Bluetooth avec driver libre. Évalué à 3.
C'est normal vu que c'est l'interface spécifier dans la norme bluetooth.
[^] # Re: Septique...
Posté par M . En réponse au journal TRON RTOS (OS temps réel japonais). Évalué à 9.
L'intérêt c'est que l'OS RT fait tout ce qui est critique (stack GSM, ...) et on délégue au Linux ce qu'il l'est moins (multimedia, GUI, réseau, ...) et que l'OS RT ne gére pas d'origine.
[^] # Re: Bonne nouvelle
Posté par M . En réponse à la dépêche Premier mobile 3G sous Linux - OpenOffice.org et la grammaire - OpenWengo cherche un nouveau nom. Évalué à 1.
http://www.languagetool.org/download/README.txt
LanguageTool, a language style checker for English, German, Polish,
and Dutch with initial support for Spanish, French, and Italian
Et puis "sont élue ai parti" aboutit après correction à "Son élue ait parti"... De même "Son élue est parti" est considéré valide.
# c'est pas nouveau
Posté par M . En réponse au journal Et hop, bientôt le Sonny Bono Act à la française !. Évalué à 1.
Sujet relancé en 2007 [2]
[1] http://www.disqueenfrance.com/snep/dossiers/2006_10.asp ...
[2] http://www.disqueenfrance.com/snep/dossiers/2007_01_14.asp
[^] # Re: Je ne comprends pas
Posté par M . En réponse à la dépêche Picidae : Une nouvelle arme libre contre la censure de l'Internet. Évalué à 3.
[^] # Re: GNASH suxorise
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 2.
# debian
Posté par M . En réponse à la dépêche Dictionnaire orthographique français inclus par défaut dans Firefox, Thunderbird et Seamonkey. Évalué à 5.
Sous debian, ca a toujours fait automatiquement...
Et même sur seamonkey...
[^] # Re: Pouah
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 2.
[^] # Re: "scout" thread ?
Posté par M . En réponse au journal Sun Rock : Les détails arrivent. Évalué à 2.
Si tu as utiliser gcov, tu as donc fait des optimisation au runtime, chose que le compilo ne sait pas faire.
Par contre ça pourrait être fait par le processeur ou une machine virtuelle.
De plus le C est très complexe à optimiser (les informations de ce que faire le programmeur sont très pauvre). Du coût la plupart du temps l'optimisation d'un code C reflète son codage
Ca améliore nettement les performances, et il ya clairement plein de choses de ce genre à faire, tout en restant portable
d'ailleurs un code C "optimiser" pour X86 peut être une grosse bousse sur une autre archi.
[^] # Re: Pouah
Posté par M . En réponse au journal [lien] Adobe : « on peut imaginer que Flash passe un jour en open-source ». Évalué à 6.