title: How to write a BitBake driver recipe which requires kernel source header files?
body: <h1>Introduction</h1>
  
  <p>I have a <code>do_install</code> task in a BitBake recipe which I've written for a driver where I execute a custom <code>install</code> script. The task fails because the installation script cannot find kernel source header files within <code>&lt;the image rootfs&gt;/usr/src/kernel</code>. This script runs fine on the generated OS.  </p>
  
  <h1>What's Happening</h1>
  
  <p>Here's the relevant part of my recipe:</p>
  
  <pre><code>SRC_URI += "file://${TOPDIR}/example"
  DEPENDS += " virtual/kernel linux-libc-headers "
  do_install () {  
     ( cd ${TOPDIR}/example/Install ; ./install )
  }
  </code></pre>
  
  <p>Here's a relevant portion of the <code>install</code> script:</p>
  
  <pre class="lang-sh prettyprint-override"><code>if [ ! -d "/usr/src/kernel/include"  ]; then
    echo ERROR: Linux kernel source include directory not found.  
    exit 1
  fi
  cd /usr/src/kernel
  make scripts
  ...
  ./install_drv pci ${DRV_ARGS}
  </code></pre>
  
  <p>I checked changing to <code>if [ ! -d "/usr/src/kernel"  ]</code>, which also failed. <code>install</code> passes different options to <code>install_drv</code>, which I have a relevant portion of below:</p>
  
  <pre class="lang-sh prettyprint-override"><code>cd ${DRV_PATH}/pci
  make NO_SYSFS=${ARG_NO_SYSFS} NO_INSTALL=${ARG_NO_INSTALL} ${ARGS_HWINT}
  if [ ${ARG_NO_INSTALL} == 0 ]; then
    if [ `/sbin/lsmod | grep -ci "uceipci"` -eq 1 ]; then
      ./unload_pci
    fi
    ./load_pci DEBUG=${ARG_DEBUG}
  fi
  </code></pre>
  
  <p>The <code>make</code> target <code>build:</code> within <code>${DRV_PATH}/pci</code> is essentially this:</p>
  
  <pre class="lang-sh prettyprint-override"><code>make -C /usr/src/kernel SUBDIRS=${PWD} modules
  </code></pre>
  
  <h1>My Research</h1>
  
  <p>I found these comments within <code>linux-libc-headers.inc</code> relevant:</p>
  
  <pre><code># You're probably looking here thinking you need to create some new copy
  # of linux-libc-headers since you have your own custom kernel. To put 
  # this simply, you DO NOT.
  #
  # Why? These headers are used to build the libc. If you customise the 
  # headers you are customising the libc and the libc becomes machine
  # specific. Most people do not add custom libc extensions to the kernel
  # and have a machine specific libc.
  #
  # But you have some kernel headers you need for some driver? That is fine
  # but get them from STAGING_KERNEL_DIR where the kernel installs itself.
  # This will make the package using them machine specific but this is much
  # better than having a machine specific C library. This does mean your 
  # recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
  # makes total sense.
  #
  # There can also be a case where your kernel extremely old and you want
  # an older libc ABI for that old kernel. The headers installed by this
  # recipe should still be a standard mainline kernel, not your own custom 
  # one.
  </code></pre>
  
  <p>I'm a bit unclear if I can 'get' the headers from the <code>STAGING_KERNEL_DIR</code> properly since I'm not using make.</p>
  
  <p>Within <code>kernel.bbclass</code> provided in the <code>meta/classes</code> directory, there is this variable assigment:</p>
  
  <pre><code># Define where the kernel headers are installed on the target as well as where
  # they are staged.
  KERNEL_SRC_PATH = "/usr/src/kernel"
  </code></pre>
  
  <p>This path is then packaged later within that <code>.bbclass</code> file here:</p>
  
  <pre><code>PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
  ...
  FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} /lib/modules/${KERNEL_VERSION}/build"
  </code></pre>
  
  <h3>Update (1/21):</h3>
  
  <p>A suggestion on the yocto IRC channel was to use the following line:</p>
  
  <pre><code>do_configure[depends] += "virtual/kernel:do_shared_workdir"
  </code></pre>
  
  <p>which is corroborated by the <a href="http://www.yoctoproject.org/docs/2.0/ref-manual/ref-manual.html#migration-1.8-kernel-build-changes" rel="noreferrer">Yocto Project Reference Manual</a>, which states that in version 1.8, there was the following change:</p>
  
  <blockquote>
    <p>The kernel build process was changed to place the source in a common shared work area and to place build artifacts separately in the source code tree. In theory, migration paths have been provided for most common usages in kernel recipes but this might not work in all cases. In particular, users need to ensure that <code>${S}</code> (source files) and <code>${B}</code> (build artifacts) are used correctly in functions such as <code>do_configure</code> and <code>do_install</code>. For kernel recipes that do not inherit from <code>kernel-yocto</code> or include <code>linux-yocto.inc</code>, you might wish to refer to the <code>linux.inc</code> file in the <code>meta-oe</code> layer for the kinds of changes you need to make. For reference, here is the commit where the <code>linux.inc</code> file in <code>meta-oe</code>was updated.</p>
    
    <p>Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the <code>do_shared_workdir</code> kernel task, for example:</p>
  
  <pre><code>do_configure[depends] += "virtual/kernel:do_shared_workdir" 
  </code></pre>
  </blockquote>
  
  <p>But I'm having difficulties applying this to my recipe.  From what I understand, I should be able to change the above line to:</p>
  
  <pre><code>do_install[depends] += "virtual/kernel:do_shared_workdir"
  </code></pre>
  
  <p>Which would mean that the <code>do_install</code> task now must be run after <code>do_shared_workdir</code> task of the <code>virtual/kernel</code> recipe, which means that I should be able to work with the shared workdir (see Question 3 below), but I still have the same missing kernel header issue.</p>
  
  <h1>My Questions</h1>
  
  <p>I'm using a custom linux kernel (v3.14) from <a href="http://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git/" rel="noreferrer">git.kernel.org</a>.  which inherits the <code>kernel</code> class.  Here are some of my questions:</p>
  
  <ol>
  <li>Shouldn't the package <code>kernel-dev</code> be a part of any recipe which inherits the <code>kernel</code> class? (<a href="http://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-PACKAGES" rel="noreferrer">this section</a> of the variables glossary)</li>
  <li>If I add the <code>virtual/kernel</code> to the <code>DEPENDS</code> variable, wouldn't that mean that the <code>kernel-dev</code> would be brought in?</li>
  <li>If <code>kernel-dev</code> is part of the dependencies of my recipe, wouldn't I be able to point to the <code>/usr/src/kernel</code> directory from my recipe? According to <a href="https://lists.yoctoproject.org/pipermail/yocto/2013-August/015792.html" rel="noreferrer">this reply on the Yocto mailing list</a>, I think I should.</li>
  <li><s>How can I properly reference the kernel source header files, preferably without changing the installation script?</s></li>
  </ol>