Ceux d'entre vous qui ont suivi de près ou de loin le développement de la série des noyaux 2.5 ont certainement remarqué qu'il était fréquemment difficile de compiler sans peaufiner méticuleusement ses options de compilation.
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
Posté par Yannick Beynet (site web personnel) . Évalué à 10.
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 . Évalué à 8.
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 ckyl . Évalué à 7.
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 Anonyme . Évalué à 2.
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 . Évalué à 8.
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 . Évalué à 6.
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
Posté par ptit_tux . Évalué à 10.
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 . Évalué à 6.
> 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 (site web personnel) . Évalué à 5.
> 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 (site web personnel) . Évalué à 2.
Heuuu, dans la vrai vie tu fais ça comment ?
[^] # Re: Pas si simple
Posté par Christophe GRAND (site web personnel) . Évalué à 1.
> 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 . Évalué à 1.
# Support des cartes reseau Broadcom 4400 (integrees aux Asus axxxx et consors)
Posté par FRLinux (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
exemple :
REG_WR(pDev, Offset_Power 0x454545)
sera remplacer par :
__rawwritel(0x454545, &((pDev)->pMemView->Offset_Power))
et ton pilote, il marche après ça ?
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.