Baslinux mailing list

[Sindi Keesan <keesan AT iamjlamb.com>]

On Fri, 11 Jun 2004, Sindi Keesan wrote:

> there is a problem in loading the module, which was compiled by 
> someone who then posted it (along with rtl8139 and tulip) for kernel 
> 2.2.16.  
> Using winbond-840.o
> insmod:  unresolved symbol pci_drv_unregister
> insmod:  unresolved symbol pci_drv_register
> 
> Is this simply a badly compiled module?  I will try to find another one 
> instead.
> 

I could not find this module for 2.2.16 anywhere else but I did find 
someone in a SuSE discussion group complaining about unresolved symbols.  
Someone advised them to recompile a different way and it worked.  So I 
need to learn to compile a kernel module. Would anyone on this list like 
to help?

Here is some info from linux forum about unresolved symbols and Makefile.

I also have a 48K file winbond-840.c.
Where do I find module.h?  There are lots of files by this name on my 
computer in various directories such as /sound.  I have installed the 
compiler software required for SW71 and also the updated glibc 2.2.5.  Do 
I need to update any other library before compiling a kernel module?

-------------------------------

    This manual is provided as a courtesy. It is not an official source.
    Please check the official manual at [124]Linux Documentation Project
                          for updated information.

         This document was last updated January 7 2004 02:57:23 PM

   The Linux Kernel Module Programming Guide
   [125]Prev Chapter 2. Hello World [126]Next
   ______________________________________________________________________

2.2. Compiling Kernel Modules

   Kernel modules need to be compiled with certain gcc options to make
   them work. In addition, they also need to be compiled with certain
   symbols defined. This is because the kernel header files need to
   behave differently, depending on whether we're compiling a kernel
   module or an executable. You can define symbols using gcc's -D option,
   or with the #define preprocessor command. We'll cover what you need to
   do in order to compile kernel modules in this section.

     * -c: A kernel module is not an independant executable, but an
       object file which will be linked into the kernel during runtime
       using insmod. As a result, modules should be compiled with the -c
       flag.
     * -O2: The kernel makes extensive use of inline functions, so
       modules must be compiled with the optimization flag turned on.
       Without optimization, some of the assembler macros calls will be
       mistaken by the compiler for function calls. This will cause
       loading the module to fail, since insmod won't find those
       functions in the kernel.
     * -W -Wall: A programming mistake can take take your system down.
       You should always turn on compiler warnings, and this applies to
       all your compiling endeavors, not just module compilation.
     * -isystem /lib/modules/`uname -r`/build/include: You must use the
       kernel headers of the kernel you're compiling against. Using the
       default /usr/include/linux won't work.
     * -D__KERNEL__: Defining this symbol tells the header files that the
       code will be run in kernel mode, not as a user process.
     * -DMODULE: This symbol tells the header files to give the
       appropriate definitions for a kernel module.

   We use gcc's -isystem option instead of -I because it tells gcc to
   surpress some "unused variable" warnings that -W -Wall causes when you
   include module.h. By using -isystem under gcc-3.0, the kernel header
   files are treated specially, and the warnings are surpressed. If you
   instead use -I (or even -isystem under gcc 2.9x), the "unused
   variable" warnings will be printed. Just ignore them if they do.

   So, let's look at a simple Makefile for compiling a module named
   hello-1.c:

   Example 2-2. Makefile for a basic kernel module
   TARGET  := hello-1
   WARN    := -W -Wall -Wstrict-prototypes -Wmissing-prototypes
   INCLUDE := -isystem /lib/modules/`uname -r`/build/include
   CFLAGS  := -O2 -DMODULE -D__KERNEL__ ${WARN} ${INCLUDE}
   CC      := gcc-3.0

   ${TARGET}.o: ${TARGET}.c

   .PHONY: clean

   clean:
       rm -rf {TARGET}.o

   As an exercise to the reader, compile hello-1.c and insert it into the
   kernel with insmod ./hello-1.o (ignore anything you see about tainted
   kernels; we'll cover that shortly). Neat, eh? All modules loaded into
   the kernel are listed in /proc/modules. Go ahead and cat that file to
   see that your module is really a part of the kernel. Congratulations,
   you are now the author of Linux kernel code! When the novelty wares
   off, remove your module from the kernel by using rmmod hello-1. Take a
   look at /var/log/messages just to see that it got logged to your
   system logfile.

   Here's another exercise to the reader. See that comment above the
   return statement in init_module()? Change the return value to
   something non-zero, recompile and load the module again. What happens?




----------------------
When I compiled before, I ran configure (which is not supplied here) to 
generate a makefile, or used a supplied Makefile and typed make all.  Do I 
simply do that here after putting the correct module.h and the 
winbond-840.c file in the same directory as Makefile?

(Another option is to give up on these two cards and use a Realtek and 
Linksys for which SW71 has modules, but what would I learn from that?)