kernel.bbclass: Remove warnings for modutils and modprobe.d

PATCH Applied Darren Hart 4 participants 8 messages Mar 7, 2012 – Mar 10, 2012

lore

Share & tools

lore

Darren Hart

author

2012-03-07 08:16 UTC #1 lore raw

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

In reply to Darren Hart

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 <[email protected]>

CC Paul Eggleton <[email protected]>

---
 meta/classes/kernel.bbclass |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

meta/classes/kernel.bbclass +10 -0

index 8fbec90..169df33 100644
@@ -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")

Signature · 1 line

1.7.6.5

Darren Hart

author

2012-03-07 08:16 UTC #0 lore raw

cover kernel.bbclass: Remove warnings for modutils and modprobe.d

The following changes since commit d7b8c247227f3cc82f92292407f548927e9fde78:

base.bbclass: Fix PACKAGECONFIG handling when no flags are set (2012-03-05 13:03:41 -0800)

are available in the git repository at:
git://git.pokylinux.org/poky-contrib dvhart/bug/2036
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=dvhart/bug/2036

Darren Hart (1):
kernel.bbclass: Remove warnings for modutils and modprobe.d

 meta/classes/kernel.bbclass |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

Signature · 1 line

1.7.6.5

Koen Kooi

2012-03-07 08:30 UTC #2 lore raw

In reply to Darren Hart

Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:

Quoted 20 lines

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 <[email protected]>
CC Paul Eggleton <[email protected]>
---
meta/classes/kernel.bbclass | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
meta/classes/kernel.bbclass +0 -0
index 8fbec90..169df33 100644

meta/classes/kernel.bbclass kernel_do_install() { · line 109

Quoted 5 lines

meta/classes/kernel.bbclass +2 -0

@@ -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

author

2012-03-07 17:16 UTC #3 lore raw

Quoted 18 lines · Koen Kooi

Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
Quoted 15 lines
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 <[email protected]>
CC Paul Eggleton <[email protected]>
---
meta/classes/kernel.bbclass | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)

Quoted 12 lines

meta/classes/kernel.bbclass kernel_do_install() { · line 109
Quoted 10 lines
meta/classes/kernel.bbclass +2 -0
index 8fbec90..169df33 100644
@@ -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.

Signature · 3 lines

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

Mark Hatle

2012-03-08 17:48 UTC #4 lore raw

Quoted 34 lines · Darren Hart

Quoted 18 lines · Koen Kooi
Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
Quoted 15 lines
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<[email protected]>
CC Paul Eggleton<[email protected]>
---
meta/classes/kernel.bbclass | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
Quoted 12 lines
meta/classes/kernel.bbclass kernel_do_install() { · line 109
Quoted 10 lines
meta/classes/kernel.bbclass +2 -0
index 8fbec90..169df33 100644
@@ -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?

Quoted 8 lines

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

Applied

2012-03-08 20:22 UTC #7 lore raw

In reply to Darren Hart

Quoted 9 lines · Darren Hart

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.

Quoted 5 lines

Signed-off-by Darren Hart <[email protected]>
CC Paul Eggleton <[email protected]>
---
 meta/classes/kernel.bbclass |   10 ++++++++++
 1 files changed, 10 insertions(+), 0 deletions(-)

Merged to master, thanks.

Richard

Richard Purdie

2012-03-08 21:16 UTC #5 lore raw

In reply to Mark Hatle

Quoted 51 lines · Mark Hatle

Quoted 34 lines · Darren Hart
Quoted 18 lines · Koen Kooi
Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
Quoted 15 lines
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<[email protected]>
CC Paul Eggleton<[email protected]>
---
meta/classes/kernel.bbclass | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
Quoted 12 lines
meta/classes/kernel.bbclass kernel_do_install() { · line 109
Quoted 10 lines
meta/classes/kernel.bbclass +2 -0
index 8fbec90..169df33 100644
@@ -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?
Quoted 8 lines
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!)

Quoted 4 lines

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

author

2012-03-10 00:08 UTC #6 lore raw

In reply to Mark Hatle

Quoted 51 lines · Mark Hatle

Quoted 34 lines · Darren Hart
Quoted 18 lines · Koen Kooi
Op 7 mrt. 2012, om 09:06 heeft Darren Hart het volgende geschreven:
Quoted 15 lines
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<[email protected]>
CC Paul Eggleton<[email protected]>
---
meta/classes/kernel.bbclass | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
Quoted 12 lines
meta/classes/kernel.bbclass kernel_do_install() { · line 109
Quoted 10 lines
meta/classes/kernel.bbclass +2 -0
index 8fbec90..169df33 100644
@@ -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?
Quoted 8 lines
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!)

Quoted 4 lines

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.

Signature · 3 lines

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