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

[Darren Hart]

On 03/08/2012 09:39 AM, 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 at linux.intel.com>
>>>> CC: Paul Eggleton<paul.eggleton at 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.

Understood. The terminology is a bit loose I guess. I understand the
distinction between linux-libc-headers and the "kernel-headers" that
most distros provide for building modules.


-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel