title: How to call exported kernel module functions from another module?
body: <p>I'm writing an API as a kernel module that provides device drivers with various functions. I wrote three functions in <strong>mycode.c</strong>. I then built and loaded the module, then copied <strong>mycode.h</strong> into <strong>&lt; kernel &gt;/include/linux</strong>. In a device driver, I have a <strong>#include &lt; linux/mycode.h &gt;</strong> and call those three functions. But when I build the driver module, I get three linker warnings saying that those <strong>functions are undefined</strong>.</p>
  <p>Notes:</p>
  <ul>
  <li>The functions are declared <strong>extern</strong> in mycode.h</li>
  <li>The functions are exported using <strong>EXPORT_SYMBOL(func_name)</strong> in mycode.c</li>
  <li>Running the command nm mycode.ko shows all three functions as being available in the symbol table (capital T next to them, meaning the symbols are found in the text (code) section)</li>
  <li>After loading the module, the command <strong>grep func_name /proc/kallsyms</strong> shows all three functions as being loaded</li>
  </ul>
  <p>So clearly the functions are being exported correctly and the kernel knows what and where they are. So why can't the driver see their definitions? Any idea what am I missing?</p>
  <hr />
  <p><strong>EDIT: I found some information about this here:</strong> <a href="http://www.kernel.org/doc/Documentation/kbuild/modules.txt" rel="nofollow noreferrer">http://www.kernel.org/doc/Documentation/kbuild/modules.txt</a></p>
  <blockquote>
  <p>Sometimes, an external module uses exported symbols from  another
  external module. kbuild needs to have full knowledge of   all symbols
  to avoid spitting out warnings about undefined    symbols. Three
  solutions exist for this situation.</p>
  <p>NOTE: The method with a top-level kbuild file is recommended    but may
  be impractical in certain situations.</p>
  <p>Use a top-level kbuild file         If you have two modules, foo.ko and
  bar.ko, where         foo.ko needs symbols from bar.ko, you can use a
  common top-level kbuild file so both modules are        compiled in the
  same build. Consider the following        directory layout:</p>
  <pre><code>  ./foo/ &lt;= contains foo.ko
    ./bar/ &lt;= contains bar.ko
  </code></pre>
  <p>The top-level kbuild file would then look like:</p>
  <pre><code>  #./Kbuild (or ./Makefile): 
        obj-y := foo/ bar/
  </code></pre>
  <p>And executing</p>
  <pre><code>  $ make -C $KDIR M=$PWD
  </code></pre>
  <p>will then do the expected and compile both modules with       full
  knowledge of symbols from either module.</p>
  <p>Use an extra Module.symvers file        When an external module is built,
  a Module.symvers file         is generated containing all exported symbols
  which are         not defined in the kernel. To get access to symbols         from
  bar.ko, copy the Module.symvers file from the         compilation of bar.ko
  to the directory where foo.ko is      built. During the module build,
  kbuild will read the      Module.symvers file in the directory of the
  external      module, and when the build is finished, a new
  Module.symvers file is created containing the sum of        all symbols
  defined and not part of the kernel.</p>
  <p>Use &quot;make&quot; variable KBUILD_EXTRA_SYMBOLS        If it is impractical to
  copy Module.symvers from      another module, you can assign a space
  separated list        of files to KBUILD_EXTRA_SYMBOLS in your build file.
  These files will be loaded by modpost during the        initialization of
  its symbol tables.</p>
  </blockquote>
  <p>But with all three of these solutions, in order for any driver to use my API, it would have to either create a new Makefile or have direct access to my Module.symvers file? That seems a bit inconvenient. I was hoping they'd just be able to #include my header file and be good to go. Do no other alternatives exist?</p>