Quoting Benoît Audouard <[EMAIL PROTECTED]>: > - eaglectrl a de grande chance de ne pas avoir été recompilé (donc ce serait > la version du compilo de mcoolive) > - et le module - lui - une très grande chance d'avoir été recompilé
Pour être plus précis c'est compilé chez MOI pour les paquets que JE mets en ligne. Ceux sur les serveurs ftp Debian ont été recompilés sur une machine des machines dédiés (plusieurs archis, fermes de compilation...) Enfin le problème est le même: eaglectrl -v ne permet pas de connaître le compilateur ayant compilé le module (note: c'est pour eaglediag). > La question qui suit est - logiquement - pourquoi le compilo a moins d'impact > sur eaglectrl que sur le module ? ya pas de structure gérée par eaglectrl ? > les interfaces avec le module sont mieux normalisées ? Ça je sais (je crois). Deux manière de communiquer avec le noyau : ioctcl, système de fichier. eaglectrl utilise ioctcl (seulement ?). En gros le module a enregistré des fonctions dans une grosse table de pointeurs de fonctions. Je me souviens plus des détails ne l'ayant pas eu l'occasion de le manipuler. Je suppose que l'on empile les paramètres sur la pile (c'est typé IOCTL ?) et on déclenche un appel système avec une entrée dans la fameuse table dans un certain registre (et il y a une macro qui écrit ça pour nous). Donc en dehors de l'ordre dans lequel on empile les paramètres sur la pile d'exécution (défini par l'ABI C) je ne vois pas de contrainte. > Et oui je comprends > tout à fait que le module étant dans le kernel. Là non plus je suis pas expert. Je DEVINE que le chargement de module c'est de l'édition de liens dynamique. Autrement dit, en compilant un module noyau on fait de la compilation séparée. Compiler un programme avec UN compilateur semble effectivement normale (pb avec les noms internes, optimisation sur les alignements et diverses conventions). Question pour les experts: je suppose qu'on ne doit jamais stripper un module. Vrai ? mcoolive.
