Articles précédents : Articles
- [36] Yopy 3700 : Vous prendrez bien un peu de Linux dans votre PDA ?
- [17] Sauvetage de films à la limite du domaine public
- [85] Licences de musique libre
- [50] Début d'une série d'articles sur Perl
- [3] Musique : « Sampling / Collage License »
- [7] VMD 1.8.1 est sorti
- [43] USB 1.1 renommé en USB 2
- [45] Encore un argument de poids pour les formats ouverts
- [25] Selon le Gartner Group, les systèmes de détection d'intrusion (IDS) seraient inutiles
- [8] « Les uvres en ligne en droit comparé : droits américain et français »
Liens connexes
- Adrian Bunk : « [2.5 patch] let broken drivers depend on BROKEN » (443 hits)
- LKML : « Linux 2.5.70 Released; Moving Toward "pre-2.6" » (332 hits)
- Kernel-Traffic #219 (373 hits)
Dépêche modérée par
Articles : Mise à l'écart de certains pilotes de périphériques dans le noyau 2.6
Posté par zyvad (). Modéré le 19 juin 2003.
![[en]](../../../images/en.png)
Adrian Bunk : « [2.5 patch] let broken drivers depend on BROKEN » (443 hits)-
LKML : « Linux 2.5.70 Released; Moving Toward "pre-2.6" » (332 hits)
-
Kernel-Traffic #219 (373 hits)
> Lire la suite (14 commentaires, moyenne: 5). [dépêche : 1668 caractères]
Une part significative des erreurs de compilation des noyaux 2.5 provient d'une non-concordance entre le code de périphériques insuffisamment maintenus et celui du noyau lui-même. En effet, malgré des appels répétés depuis parfois plusieurs années, certains périphériques peu utilisés ou ne suscitant plus l'intérêt d'un mainteneur sont petit à petit dans l'incapacité de compiler.
Le message d'Adrian Bunk témoigne, à mon avis, de l'état du consensus de la communauté actuelle des développeurs : même lorsqu'ils sont trop obsolètes pour simplement pouvoir compiler sans modifications importantes, les codes historiques des pilotes de ces périphériques resteront dans le tarball du noyau.
On peut se souvenir que, lors de la sortie du 2.4, Linus Torvalds avait exprimé un certain regret de voir les versions finales du 2.3 peu testées.
Je rajoute un lien sur le numéro 219 de l'excellent "kernel traffic" (http://kt.zork.net) qui aborde en divers endroits ce sujet.
Le message d'Adrian Bunk :
« The patch below isn't meant to be applied now, a similar patch should be applied soon before 2.6.0.
This patch adds a dependency on an undefined BROKEN to all drivers that have longstanding compile errors.
Additionally I'll add a
config BROKEN_ON_SMP
default y if !SMP"
and add BROKEN_ON_SMP to the dependencies of drivers that don't compile with SMP enabled (e.g. because of cli/sti usage). »
Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
woww !
C'est plutôt une bonne nouvelle. A mon avis la stabilité n'en sera que meilleur. Et puis, comme ça les utilisateurs seront informés des pilotes qui sont le plus mis à jour (pas facile sinon de savoir si le mainteneur est réactif ou non avant de commencer à utiliser).
-
[^]Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
Posté par lezardbreton (Jabber id, page perso, ) le 19/06/2003 à 12:54. (lien). Évalué à 8.C'est effectivement plutôt une bonne nouvelle, ce qui m'inquiète, c'est que les développeurs du noyau n'ait pas assez de statistiques sur l'utilisation du matériel des utilisateurs.
Je m'explique, comment font-ils pour savoir quels sont les pilotes qui même s'ils ne sont pas activement maintenus, sont utilisés dans la communauté ? Je sais que sur la gentoo, il existe un paquet permettant de recenser les configurations des utilisateurs. Il me semble qu'il en existe un aussi sur la Debian, mais je ne me rappelle plus son nom.
Ceci permettrait peut-être d'insister sur ces pilotes, non ?-
[^]Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
Posté par cykl (Jabber id, ) le 19/06/2003 à 13:36. (lien). Évalué à 7.Ils ne font pas, ca explique peut etre pourquoi les appareils photo Sony P*2 ne sont pas supporte dans le 2.4.21 alors qu'il suffit de 4 lignes pour que cela fonctionne...
Et oui le rapport a deja ete envoye il y'a un ptit bout de temps : Fin mars...
Aller peut etre que l'annee prochaine on n'aura plus a recompiler les stations de travail pour que ca fonctionne !
-
[^]Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
Posté par gnap gnap (page perso, ) le 19/06/2003 à 15:41. (lien). Évalué à 2.apt-get install popularity-contest
http://people.debian.org/~apenwarr/popcon/(...)
-
[^]Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
Posté par zyvad () le 19/06/2003 à 17:08. (lien). Évalué à 8.Malheureusement, le developpement de pilotes de périphériques ne requiert pas que du travail : il requiert aussi un accès aux spécifications du matériel et la possibilité de débattre sereinement avec les concepteurs du matériel de "divergences entre la spécification et le comportement observé du périphérique". Quand on regarde un peu les changelogs du 2.5.71 (par exemple), on voit bien que certains pilotes sont bien plus fréquemment maintenus que d'autres.
Par ailleurs, quand on regarde les sources de certains pilotes, on voit bien que les dernières modifications significatives remontent parfois à 1999. Entre temps, le noyau a évolué : mais doit-on pour autant sortir du tarball du noyau des codes qui seront peut-être repris par des utilisateurs motivés ?
Le 2.6-pre étant en vue, ce qui est important est que la série 2.5 commence à être testée dans les environnements les plus divers. Or, actuellement, compiler un 2.5.70+ exige de savoir reconnaître un driver qui ne compile pas et ne compilera pas sans sérieuses retouches : avec un option "ne même pas essayer les drivers notoirement foireux", plus de gens pourront essayer.-
[^]Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
Posté par Christophe () le 19/06/2003 à 20:35. (lien). Évalué à 6.Je pense qu'il faut se mettre d'accord sur ce que veut dire maintenu, bien maintenu.
Je precise ma pensee : si un driver est au point, il n'apparaitra pas dans le Changelog, pourtant cela ne veut pas dire qu'il n'est plus ni mal maintenu.
A mon avis pour estimer la qualite de la maintenance d'un driver il faudrait plutot observer le temps ecoule entre le rapport de bug et la correction (eventuelle, si il n'y en a pas c'est que le driver n'est pas/plus maintenu).
Pour ce qui est des tests du 2.5, un processus long et fastidieux mais efficace est de compiler son noyau par etape :
0. noyau de base
1. version 0 +1 driver
2. version 1 + 1 driver
...
comme ca tu sais tout de suite d'ou vient le probleme. Conseil a deux balles puisque les utilisateurs lambda ont maintenant cette option magique.
-
-
Re: Mise à l'écart certains de pilotes de périphériques dans le noyau 2.6
En gros, on indique si le driver n'est pas maintenu et s'il n'est pas maintenu, faut pas te plaindre car t'as été prévenu. Ou si tu veux être sure que ça marche il faut choisir du matos qui est indiqué comme maintenu. C'est un plus, tu sais où tu mets les pieds.
Cette transparence va pousser les gens a prendre du matos bien maintenu. Les constructeur de matos vont devoir mettre la main à la pate pour ne pas manquer un marché.
Redhat va faire pareil en indiquant s'il supporte ou non certains drivers. Dans rawhide, il y a maintenant un paquet kernel-unsupported :
Description :
This packages contains extra modules for drivers that are in the kernel.org
kernel but that Red Hat can't test properly, but provides as courtosy for
people who want to use these regardless.
NB: Ce qui est considéré comme maintenu par le "team" Linux, c'est pas forcément supporté (ou testé pour reprendre leur terme) par Redhat. Il y a actuellement plus de 300 drivers indiqué comme non supportés/testés par Redhat dont reiserfs. Ça ne veut pas dire que ces drivers sont de mauvaises qualités !
-
[^]Pas si simple
Posté par manuel () le 19/06/2003 à 17:01. (lien). Évalué à 6.> Cette transparence va pousser les gens a prendre du matos
> bien maintenu. Les constructeur de matos vont devoir mettre
> la main à la pate pour ne pas manquer un marché.
Quand le driver d'un matos bien maintenu ne l'est plus, le
matos devient du matos mal maintenu, que le constructeur
ait mis la main à la pate, ou pas.
manuel-
[^]Re: Pas si simple
Posté par Christophe GRAND (page perso, ) le 19/06/2003 à 21:02. (lien). Évalué à 5.> Quand le driver d'un matos bien maintenu ne l'est plus, le
> matos devient du matos mal maintenu, que le constructeur
> ait mis la main à la pate, ou pas.
Mettre la main à la pâte n'est pas un fait ponctuel : le support est une action continue. A un instant donné, il devrait être possible de dire quels drivers/préiphériques sont activement supportés.
Pour te prémunir des périphériques dont le support dure aussi longtemps que la neige en plein soleil, il n'y a que deux solutions :
1/ tu prends du matos "standard" et de marque sérieuse
2/ tu contractes avec le fabriquant une garantie de support
et une troisième pour nous, les gnous ou pour ceux qui emploient des gnous :
3/ tu assures le support toi-même
Pour le particulier non-kernel-hacker (il y en a ?) il n'y a que la solution 1.
Cette décision d'Adrian Bunk permet simplement d'identifier plus facilement les boîtes pas du tout sérieuses. Bouh les vilaines ;-)
(je sens que je devrais me relire... hum... non !)-
[^]Re: Pas si simple
Posté par Christophe Merlet (page perso, ) le 19/06/2003 à 22:12. (lien). Évalué à 2.> 2/ tu contractes avec le fabriquant une garantie de support
Heuuu, dans la vrai vie tu fais ça comment ?-
[^]Re: Pas si simple
Posté par Christophe GRAND (page perso, ) le 19/06/2003 à 23:45. (lien). Évalué à 1.> > 2/ tu contractes avec le fabriquant une garantie de support
> Heuuu, dans la vrai vie tu fais ça comment ?
C'est un contrat de support ! C'est tout. Comme tout contrat, les termes s'en négocient. Le pouvoir de négociation varie selon la corpulence (PME ou Fortune 500).
-
-
[^]Re: Pas si simple
Posté par manuel () le 23/06/2003 à 09:36. (lien). Évalué à 1.> > Quand le driver d'un matos bien maintenu ne l'est plus, le > > matos devient du matos mal maintenu, que le constructeur > > ait mis la main à la pate, ou pas. > > [...] le support est une action continue [...] il devrait être > possible de dire quels drivers/périphériques sont activement > supportés [...] tu prends du matos "standard" et de marque > sérieuse [...] Cette décision d'Adrian Bunk permet simplement > d'identifier plus facilement les boîtes pas du tout sérieuses Ouais, ben c'est bien ce que je disais, c'est pas si simple :-) Les drivers qui posent problème en 2.6 ne sont ils pas avant tout des drivers dont le code source doit être revu par leurs auteurs à la suite de diverses modification dans le Kernel ? manuel
-
-
Support des cartes reseau Broadcom 4400 (integrees aux Asus axxxx et consors)
Un peu hors sujet, si certains utilisent gcc 3.3 (Debian sid, SuSE 8.2, cooker ...) et ont les pilotes d'Asus a ce sujet, le pilote fournit ne compile plus.
L'utilisation de ## pour les fonctions semble poser probleme. Je suis pas specialiste en C mais le retirer marche et le driver compile correctement.
Il faut pour cela editer b44.h et appliquer ca :
--- b44.h.orig 2003-06-06 11:46:07.000000000 +0100
+++ b44.h 2003-06-06 11:46:25.000000000 +0100
@@ -1079,10 +1079,10 @@
/******************************************************************************/
#define REG_RD(pDevice, OffsetName) \
- __raw_readl(&((pDevice)->pMemView->##OffsetName))
+ __raw_readl(&((pDevice)->pMemView->OffsetName))
#define REG_WR(pDevice, OffsetName, Value32) \
- (void) __raw_writel(Value32, &((pDevice)->pMemView->##OffsetName))
+ (void) __raw_writel(Value32, &((pDevice)->pMemView->OffsetName))
#define REG_RD_OFFSET(pDevice, Offset) \
__raw_readl(((LM_UINT8 *) (pDevice)->pMemView + Offset))
Steph
-
[^]Re: Support des cartes reseau Broadcom 4400 (integrees aux Asus axxxx et consors)
Posté par Pooly (page perso, ) le 20/06/2003 à 09:14. (lien). Évalué à 1.Ouais, mais c'est un define, et le ## permet de remplacer le ##OffsetName par la chaine de caractère donner en argument.
exemple :
REG_WR(pDev, Offset_Power 0x454545)
sera remplacer par :
__rawwritel(0x454545, &((pDev)->pMemView->Offset_Power))
et ton pilote, il marche après ça ?
Cette page a été générée par Templeet en 0.1386s (dont 0.065 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.