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

login
register
mail settings
Submitter Darren Hart
Date March 7, 2012, 8:06 a.m.
Message ID <83eeb4ed11a6a63abda1f3978c849a46516b92a1.1331107546.git.dvhart@linux.intel.com>
Download mbox | patch
Permalink /patch/22859/
State Accepted
Commit 6068f3229397baf561b1e84a22b570a803d95c49
Headers show

Comments

Darren Hart - March 7, 2012, 8:06 a.m.
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(-)
Koen Kooi - March 7, 2012, 8:21 a.m.
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?

regards,

Koen
Darren Hart - March 7, 2012, 5:04 p.m.
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.
Mark Hatle - March 8, 2012, 5:39 p.m.
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.

--Mark
Richard Purdie - March 8, 2012, 8:13 p.m.
On Wed, 2012-03-07 at 00:06 -0800, Darren Hart wrote:
> 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(-)

Merged to master, thanks.

Richard
Richard Purdie - March 8, 2012, 9:07 p.m.
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
Darren Hart - March 9, 2012, 11:58 p.m.
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@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.

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.

Patch

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"
 	else
 		bbnote "no modules to install"
 	fi
@@ -450,6 +452,14 @@  python populate_packages_prepend () {
 	do_split_packages(d, root='/lib/firmware', file_regex='^(.*)\.cis$', output_pattern='kernel-firmware-%s', description='Firmware for %s', recursive=True, extra_depends='')
 	do_split_packages(d, root='/lib/modules', file_regex=module_regex, output_pattern=module_pattern, description='%s kernel module', postinst=postinst, postrm=postrm, recursive=True, hook=frob_metadata, extra_depends='update-modules kernel-%s' % d.getVar("KERNEL_VERSION", True))
 
+	# If modutils and modprobe.d are empty at this point, remove them to
+	# avoid warnings. removedirs only raises an OSError if an empty
+	# directory cannot be removed.
+	dvar = d.getVar('PKGD', True)
+	for dir in ["%s/etc/modutils" % (dvar), "%s/etc/modprobe.d" % (dvar)]:
+		if len(os.listdir(dir)) == 0:
+			os.rmdir(dir)
+
 	import re
 	metapkg = "kernel-modules"
 	d.setVar('ALLOW_EMPTY_' + metapkg, "1")