Olivier Allard-Jacquin wrote:
> Hello,
>
>> Bonjour,
>>
>> Je suis en train de tuner mon kernel à partir des sources fournis en
>> RPM par
>> Mandrake (puisque j'utilise une mandrake)
>>
>> Et lorsque j'ai voulu appliquer les patches de swsusp 1.0 j'ai eu des
>> problèmes
>> de hunk rejected... normal car une version apparemment autre que 1.0
>> avait
>> déjà été appliquée. Donc impossible d'envisager le patche 1.0.3
>
>
> Effectivement: Rare sont les patchs kernel que l'on peut appliquer
> sur le Kernel de Mandrake, vu que celui-ci est déjà patché.
>
> Pour avoir moi aussi cherché dans cette voie-là, je me suis rendu
> compte que Mandrake mettait pas mal de patchs dans ses distribs.
> Il faut que tu reprennes un kernel non patché, et que tu rajoutes un a
> un les patchs dont tu as besoin, voir ceux que Mandrake utilise aussi.
>
> Un conseil: Modifie dans le "Makefile" le paramètre "EXTRAVERSION",
> avec une valeur comme "custom1", "custom2", etc... Cela te permettra de
> compiler plusieurs version de ton kernel personnalisé, tout en séparent
> bien tes propres version du kernel et de ses modules. Dans ton
> /lib/modules/, tu auras ceci :
> /lib/modules/2.4.21-custom1/
> /lib/modules/2.4.21-custom2/
> ....
>
>> Est-il possible de connaître les patches qui ont été appliqués sur un
>> kernel ? Le fichier de config ne suffit pas car les numéros de
>> version des
>> patches ne sont pas visibles - on peut éventuellement trouvé dans
>> Documentation
>> des fichiers avec un numéro mais on n'a pas une vue synthétique de
>> l'état des
>> sources.
>> Est-ce qu'un système de gestion de version existe ?
>
>
> Pas à ma connaissance. Cette question a déjà été posé ici, sans pour
> autant y trouver de réponse.
>
>> Bien sur, rien de mieux que de récupérer le kernel officiel et
>> d'appliquer
>> ces patches en conservant un fichier d'historique... mais comme j'ai
>> déjà
>> fait pas mal de travail sur le 2.4.21 de mandrake je voulu éviter de
>> recommencer.
>
>
> 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"
>
>
>> Autre question: quelles sont les options de compilation qui pourrait
>> faire
>> qu'un module binaire propriétaire pour un winmodem fonctionne sur le
>> kernel 2.4.19 de la woody mais ne fonctionne pas dans un kernel
>> 2.4.19 de
>> mandrake ?
>
>
> 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.
>
>> 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.
>
>> J'ai compilé le kernel 2.4.21 avec un 2.95 et toujours le même problème.
>> Y-a-t-il une différence avec un gcc 2.93 ?
>> Faut-il regardé du coté des options de compilation du kernel (stack
>> frame) ?
>>
>> Bref, la voie du kernel est longue et difficile.
>
>
> Oui !! :=)
>
>> Merci d'avance pour toute aide - et bon dimanche
>
>
> Bonne journée,
>
> Olivier
>
>
>
>
