a problem of kernel-module version mismatch.

[Ming Liu]

Dear Arnd,
Thanks a lot for your help. Now I have solved the problem of version 
mismatch. The reason is I haven't include the sentence of "#define MODULE". 


However the problem of unresolved symbol XIo_In32 and XIo_Out32 still 
exists. I will try to solve it following your suggestion. If any question, 
I will ask you again. Thanks a lot for your help.

Regards
Ming


>From: Arnd Bergmann <arnd.bergmann at de.ibm.com>
>To: "Ming Liu" <eemingliu at hotmail.com>
>CC: linuxppc-embedded at ozlabs.org
>Subject: Re: a problem of kernel-module version mismatch.
>Date: Thu, 8 Jun 2006 17:25:37 +0200
>
>On Thursday 08 June 2006 15:52, Ming Liu wrote:
> > >The easiest way is usually to put the driver in your source tree
> > >and compile everything together. That also makes it easier to
> > >distribute the complete source tree to your users.
> >
> > Sorry that I am a novice in Linux. I don't know how can I put the 
driver in
> > my source tree and compile everything together. It looks like that 
there is
> > no option in the menuconfig to choose a specially customed peripheral. 
So I
> > think I only can include the customed peripheral as a module. Could you
> > please say in a detail on how to do that?
>
>The most simple way would be to put it into linux/drivers/misc and add it
>to the Makefile in there.
>
> > > > insmod: unresolved symbol XIo_In32
> > > > insmod: unresolved symbol XIO_Out32
> > >
> > >that looks like part of your module is missing. Try to find where 
thses
> > >functions are defined in there and why that isn't compiled.
> >
> > It's very strange because I have checked the source. In the header file 
of
> > xio.h, there are the following sentences,
> >
> > /************************** Function Prototypes
> > ******************************/
> >
> > /* The following functions allow the software to be transportable 
across
> > ? processors which may use memory mapped I/O or I/O which is mapped 
into a
> > ? seperate address space such as X86.  The functions are better suited 
for
> > ? debugging and are therefore the default implementation. Macros can
> > instead
> > ? be used if USE_IO_MACROS is defined.
> > ?/
> > #ifndef USE_IO_MACROS
>
>The comment tells you that you either need to implement these functions
>youself or #define USE_IO_MACROS in the code before this.
>
> > /* Functions */
> > Xuint8 XIo_In8(XIo_Address InAddress);
> > Xuint16 XIo_In16(XIo_Address InAddress);
> > Xuint32 XIo_In32(XIo_Address InAddress);
> >
> > void XIo_Out8(XIo_Address OutAddress, Xuint8 Value);
> > void XIo_Out16(XIo_Address OutAddress, Xuint16 Value);
> > void XIo_Out32(XIo_Address OutAddress, Xuint32 Value);
> >
> > #else
> >
> > /* The following macros allow optimized I/O operations for memory 
mapped
> > I/O
> > ? Note that the SYNCHRONIZE_IO may be moved by the compiler during
> > ? optimization.
> > ?/
> >
> > #define XIo_In8(InputPtr) ?*(volatile Xuint8 ?)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In16(InputPtr) (*(volatile Xuint16 *)(InputPtr));
> > SYNCHRONIZE_IO;
> > #define XIo_In32(InputPtr) (*(volatile Xuint32 *)(InputPtr));
> > SYNCHRONIZE_IO;
> >
> > #define XIo_Out8(OutputPtr, Value)  \
> > ??{ (*(volatile Xuint8 ?)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out16(OutputPtr, Value) \
> > ??{ (*(volatile Xuint16 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> > #define XIo_Out32(OutputPtr, Value) \
> > ??{ (*(volatile Xuint32 *)(OutputPtr) = Value); SYNCHRONIZE_IO; }
> >
> > #endif
>
>These macros are probably broken on powerpc.
>
> >
> > I think these are the defination of XIo_In32 and XIo_Out32. Also, 
during
> > the compilation, there is no error to complain that "XIo_In32 or 
XIo_Out32
> > undeclared".
> >
>
>I would suggest you remove that part of the header file completely, and
>replace it with:
>
>#define XIo_In32(p) in_le32(x)
>#define XIO_Out32(p,v) out_le32(p, v)
>
>	Arnd <><

_________________________________________________________________
ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger:  http://messenger.msn.com/cn