Re: [PATCH 1/1] kernel.bbclass: Remove warnings for modutils and modprobe.d

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2012-03-08 at 11:39 -0600, Mark Hatle wrote:
> On 3/7/12 11:04 AM, Darren Hart wrote:
> >
> >
> > On 03/07/2012 12:21 AM, Koen Kooi wrote:
> >>
> >> Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
> >>
> >>> Fixes [Yocto #2036]
> >>>
> >>> The source and build directories are unused, remove them.
> >>>
> >>> The modutils and modprobe.d directories may be used if modules are built that
> >>> are either autoloaded or have modprobe.d entries. This isn't known at install
> >>> time, so check after the package split if these directories are empty and
> >>> remove them if they are.
> >>>
> >>> Signed-off-by: Darren Hart<dvhart@linux.intel.com>
> >>> CC: Paul Eggleton<paul.eggleton@linux.intel.com>
> >>> ---
> >>> meta/classes/kernel.bbclass |   10 ++++++++++
> >>> 1 files changed, 10 insertions(+), 0 deletions(-)
> >>>
> >>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> >>> index 8fbec90..169df33 100644
> >>> --- a/meta/classes/kernel.bbclass
> >>> +++ b/meta/classes/kernel.bbclass
> >>> @@ -105,6 +105,8 @@ kernel_do_install() {
> >>> 		oe_runmake DEPMOD=echo INSTALL_MOD_PATH="${D}" modules_install
> >>> 		rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.order"
> >>> 		rm -f "${D}/lib/modules/${KERNEL_VERSION}/modules.builtin"
> >>> +		rm "${D}/lib/modules/${KERNEL_VERSION}/build"
> >>> +		rm "${D}/lib/modules/${KERNEL_VERSION}/source"
> >>
> >> How do you want to support on-target building of exernal modules?
> >
> > That is an open issue that needs to be addressed, but we don't install
> > the build or source directories now (unless I'm missing something), so
> > these are links to nowhere at the moment.
> >
> > We do have a bug open to support on-target module building. I supect
> > we'll need to add these as part of a headers package or similar. So
> > these may come back.
> >
> 
> Just as a note..  headers package(s) are the wrong way to support kernel modules 
> compilation on the target.  You really need to supply a configured kernel source 
> tree --- often you can dump the .c files though.  Kernel headers (for module 
> compilation) and userspace are often intentionally different.. and people get 
> this confused often.  (I can't express how often I've had to convince someone 
> that, no you can't guaranty a working kernel module from the stuff in /usr/include!)
> 
> The right approach is to provide, as part of the kernel itself, a source 
> tree/headers package tha installes into the 
> "{D}/lib/modules/${KERNEL_VERSION}/source" (or similar) directory, and instruct 
> people to use that location when building kernel modules on the target.

We already provide such a source tree for external module compilation
within the build itself. There is also an open bug to provide the same
tree for on-target use so I think we have a good plan which is
consistent with the above. For now I really want to clean up the warning
messages. We can add correct symlinks once we have on target support so
I've taken Darren's patch.

Cheers,

Richard