Re: Compilation Kernel et application de patches

Page principale

Répondre à ce message
Auteur: Yves Martin
Date:  
À: guilde
Sujet: Re: Compilation Kernel et application de patches
Selon Jean-Noel Avila <jean-noel.avila@???>:

> >     Pour réutiliser le travaille de sélection de package que tu as déjà 
> > fait, il suffit de récupérer le fichier ".config" du répertoire de tes 
> > sources de Mandrake: /usr/src/linux/.config par défaut.

> >
> >     Tu peux ensuite utiliser ce fichier dans un autre source de kernel 
> > Linux, en utilisant:

> >
> >     make mrproper
> >     make oldconfig  , et tu réponds aux questions
> > Puis après le classique "make xconfig"


Merci Olivier pour l'astuce !

J'ai effectivement repris un kernel tout propre - en jetant les patches
pour ALSA, bootsplash, XFS, ...

Mon portable fonctionne toujours: vidéo, fb, sound OSS, USB, devfs, ...
L'essentiel quoi !

> >     Ton module binaire a été compilé pour une certaine version d'un 
> > kernel, ce qui crée entre autre une certaine spécification au niveau de 
> > l'édition de liens. C'est à dire que ce module NE peut PAS fonctionner 
> > avec un autre kernel. Il faut demander au fournisseur de ton driver une 
> > nouvelle version. Ou qu'il libère les sources du driver ! :=))

>
> Ce n'est pas totalement vrai : par défaut, on se fait jeter mais avec
> l'option kivabien, >insmod -f toto, on parvient à charger le modules. A
> ses risques et périls. Pour des versions de kernel assez proches et pas
> trop patchées, on peut avoir quelque chose de stable (essais faits avec
> un dongle sur port parallèle). Mais la solution la plus sure reste
> d'avoir les sources du module.


Voici un script qui utilise objdump pour récupérer les noms symboliques
du kernel et mettre à jour le module en conséquence:

http://sidlo.penguin.cz/ES2838/index_en.html

Bref, insmod -f n'est plus utilie

> >> Symptome: kernel panic avec un problème d'arguments dans les handlers
> >> d'interruption
> >>
> >> Hypothèse: les binaires générés avec gcc 3.2 ne semble pas compatible
> >> avec
> >> un module compilé avec un gcc 2.9x


> >     Un changement de compilateur entre module et kernel est 
> > effectivement un source de problème.


Apparemment ESS refuse de libérer ces sources car il contient la valeur
ajouté de sa carte - et donc pourrait profiter à la concurrence.
Heureusement HP a mandaté Mandrake pour faire une compilation de ce
driver Linux et le délivrer en binaire.

  Plusieurs personnes affirment avoir fait marché ce driver sur le 2.4.19:
    http://www.wir-sind.org/poeschl/xt1000/
  [ Nombreux sont ceux qui ont abandonné et acheté un modem pcmcia ]


Moi-même je viens de réussir ce matin... en prenant le driver 2.4.18
de Debian Woody sous forme binaire - tout fonctionne impéccable dans minicom.
ATI0 à 7 sans problème !! Pas de kernel panic.
Alors que le module a été compilé pour le 2.4.18 de Mandrake.

Il me faut maintenant savoir comment ce kernel a été compilé pour reproduire
la chose sur le module 2.4.21 si c'est possible. Est-ce que les processus
Debian permette de connaître les options de compilation et la version de
gcc utilisé ?

Comme c'est un driver modem, j'espère que les structures utilisés par les
tty n'ont pas trop changé... Sinon je ferai le nécessaire, mais j'y
arriverait ! L'espoir fait vivre.

--
Yves Martin