(Courriels de diversion: <paternite@detartreraient-entachant.com> <accoupla@prononciation-reproduirons.com> <vociferaient@eloigna-atermoierais.com> <retercer@transportais-gendarmees.com> <vinicole@troqueraient-agrafes.com> <assiettes@hippiques-endurerai.com> <revolutionnees@financaient-personnifieriez.com> <enrobee@electrisant-transiterions.com> <dialecte@depassait-repudiees.com> <filmerais@couvre-chef-tritureras.com> )
Guillaume Betous a écrit : >> Je ne vois pas l'int�r�t. >> Si c'est pour recopier le fichier, je peux le recopier � la main. >> > > Si tu es sur de toi... > > >> et bien non, puisque dmesg me dit: >> udf: disagrees about version of symbol struct_module >> > > Si je comprends bien (parce que j'avais pas compris ça), tu tentes de > compiler un module d'une nouvelle version du noyau ? Et tu ne veux pas > recompiler le noyau en entier pour simplement profiter de la nouvelle > version du module... > > (...) > En tous cas, si > j'ai bien compris, le système de versions est justement là pour éviter > de faire ce que tu tentes de faire... c'est que c'est pas la bonne façon > de s'y prendre ! > Je lis dans Linux Device Drivers (isbn 1-56592-292-1), au sujet des noyaux 2.0 et 1.2: «One of the main problems with modules is their version dependency... The idea is that a module is incompatible with a different kernel version only if the software interface offfered by the kernel has changed. The software interface, then, can, be represented by a function prototype and the exact definition of all data structures involved in the function call. Finally, a CRC algorithm can be used to map all the information about the software interface to a single 32 bit number [with a note on (non-)SMP modules using inline]. The issue of version dependence is thus handled by mangling the name of each symbol exported by the kernel... This information is optional and can be enabled at compilation time.» Je pense qu'aujourd'hui le système doit être similaire, dans le principe, mais différent dans les détails techniques de mise en œuvre. Dans ce contexte, je ne comprend pas pourquoi le noyau 2.6.18-machin ne serait pas compatible avec un module 2.6.18-truc, compilé avec les headers d'un noyau 2.6.18-bidule. Ce même livre aborde le symbole __NO_VERSION__ qui servirait à compiler des modules indépendants du noyau... -------------------------------------------------------------------- Les listes de diffusion occultes: <URL:http://www.CULTe.org/listes/>