[PATCH 0/2] fixing kernel module cross-recipe dependency

[PATCH 0/2] fixing kernel module cross-recipe dependency

[André Draszik]

Hi,

In a situation where multiple external kernel modules are built
from multiple independent recipes, we currently don't generate
correct runtime dependencies of the packages created.

This (small) series of patches attempts to address this.

It's working well for me but there'll likely be cases I haven't
considered.

Cheers,
Andre'

[PATCH 1/2] module.bbclass: use Module.symvers for dependants

[André Draszik]

When compiling multiple external kernel modules, where one
depends on the other, there are two problems at the
moment:
1) we get compile time warnings from the kernel build
   system due to missing symbols (from modpost).
2) Any modules generated are missing dependency
   information (in the .modinfo elf section) for any
   dependencies outside the current source tree and
   outside the kernel itself.

This is expected, but the kernel build system has a way to
deal with this - the dependent module is expected to
specify KBUILD_EXTRA_SYMBOLS (as a space-separated list)
to point to any and all Module.symvers of kernel modules
that are dependencies.

While problems 1) and 2) by themselves are not big issues,
they prevent the packaging process from generating cross-
source tree package dependencies.

As a first step to solve this, we:
1) install Module.symvers of all external kernel module
   builds (into a location that is automatically packaged
   into the -dev package)
2) make use of KBUILD_EXTRA_SYMBOLS and pass the location
   of all Module.symvers of all kernel-module-* packages
   we depend on

Signed-off-by: André Draszik <git@andred.net>
---
 meta/classes/module.bbclass | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index 01c9309..68e3d34 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -8,6 +8,15 @@ EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
 
 MODULES_INSTALL_TARGET ?= "modules_install"
 
+python __anonymous () {
+    depends = d.getVar('DEPENDS', True)
+    extra_symbols = []
+    for dep in depends.split():
+        if dep.startswith("kernel-module-"):
+            extra_symbols.append("${STAGING_INCDIR}/" + dep + "/Module.symvers")
+    d.setVar('KBUILD_EXTRA_SYMBOLS', " ".join(extra_symbols))
+}
+
 module_do_compile() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
@@ -15,6 +24,7 @@ module_do_compile() {
 		   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 		   AR="${KERNEL_AR}" \
 	           O=${STAGING_KERNEL_BUILDDIR} \
+		   KBUILD_EXTRA_SYMBOLS="${KBUILD_EXTRA_SYMBOLS}" \
 		   ${MAKE_TARGETS}
 }
 
@@ -24,6 +34,11 @@ module_do_install() {
 	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 	           O=${STAGING_KERNEL_BUILDDIR} \
 	           ${MODULES_INSTALL_TARGET}
+
+	install -d -m0755 ${D}${includedir}/${BPN}
+	cp -a --no-preserve=ownership ${B}/Module.symvers ${D}${includedir}/${BPN}
+	# it doesn't actually seem to matter which path is specified here
+	sed -e 's:${B}/::g' -i ${D}${includedir}/${BPN}/Module.symvers
 }
 
 EXPORT_FUNCTIONS do_compile do_install
-- 
2.9.3

[PATCH 2/2] kernel-module-split.bbclass: generate dependencies across recipes

[André Draszik]

The information retrieved via depmod is incomplete with
regards to kernel modules that are dependencies, in
particular where two kernel modules are build from
different source trees / recipes, which leads to incomplete
dependency information for packages created.

So far, our packages created didn't contain dependencies on
packages created by other recipes, as we solely use depmod
for that, and depmod can only work well after *all* kernel
modules have been copied into one place - it doesn't work
well in a staged approach.

Now that all .ko have correct dependency information at packaging
time, we can use that information to properly track dependencies
across recipies, and can combine the information from the
.modinfo elf section with the information from depmod.

Signed-off-by: André Draszik <git@andred.net>
---
 meta/classes/kernel-module-split.bbclass | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index ed42d2b..db0ad33 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -173,7 +173,15 @@ python split_kernel_module_packages () {
             d.setVar('DESCRIPTION_' + pkg, old_desc + "; " + vals["description"])
 
         rdepends = bb.utils.explode_dep_versions2(d.getVar('RDEPENDS_' + pkg, True) or "")
-        for dep in get_dependencies(file, pattern, format):
+        modinfo_deps = []
+        if "depends" in vals and vals["depends"] != "":
+            for dep in vals["depends"].split(","):
+                on = legitimize_package_name(dep)
+                dependency_pkg = format % on
+                modinfo_deps.append(dependency_pkg)
+        depmod_deps = get_dependencies(file, pattern, format)
+        all_deps = list(set(modinfo_deps + depmod_deps))
+        for dep in all_deps:
             if not dep in rdepends:
                 rdepends[dep] = []
         d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends, commasep=False))
-- 
2.9.3

[PATCH] kernel-module-split.bbclass: no need for running depmod

[André Draszik]

With the recent changes, executing depmod is not needed
anymore.

This simplifies and remove a lot of unnecessary code.

Signed-off-by: André Draszik <git@andred.net>
---
 meta/classes/kernel-module-split.bbclass | 67 +-------------------------------
 1 file changed, 1 insertion(+), 66 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index db0ad33..9518747 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -63,68 +63,6 @@ python split_kernel_module_packages () {
             vals[m.group(1)] = m.group(2)
         return vals
 
-    def parse_depmod():
-
-        dvar = d.getVar('PKGD', True)
-
-        kernelver = d.getVar('KERNEL_VERSION', True)
-        kernelver_stripped = kernelver
-        m = kerverrexp.match(kernelver)
-        if m:
-            kernelver_stripped = m.group(1)
-        staging_kernel_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
-        system_map_file = "%s/boot/System.map-%s" % (dvar, kernelver)
-        if not os.path.exists(system_map_file):
-            system_map_file = "%s/System.map-%s" % (staging_kernel_dir, kernelver)
-            if not os.path.exists(system_map_file):
-                bb.fatal("System.map-%s does not exist in '%s/boot' nor STAGING_KERNEL_BUILDDIR '%s'" % (kernelver, dvar, staging_kernel_dir))
-
-        cmd = "depmod -n -a -b %s -F %s %s" % (dvar, system_map_file, kernelver_stripped)
-        f = os.popen(cmd, 'r')
-
-        deps = {}
-        line = f.readline()
-        while line:
-            if not depmodpat0.match(line):
-                line = f.readline()
-                continue
-            m1 = depmodpat1.match(line)
-            if m1:
-                deps[m1.group(1)] = m1.group(2).split()
-            else:
-                m2 = depmodpat2.match(line)
-                if m2:
-                    deps[m2.group(1)] = m2.group(2).split()
-                    line = f.readline()
-                    m3 = depmodpat3.match(line)
-                    while m3:
-                        deps[m2.group(1)].extend(m3.group(1).split())
-                        line = f.readline()
-                        m3 = depmodpat3.match(line)
-                    m4 = depmodpat4.match(line)
-                    deps[m2.group(1)].extend(m4.group(1).split())
-            line = f.readline()
-        f.close()
-        return deps
-
-    def get_dependencies(file, pattern, format):
-        # file no longer includes PKGD
-        file = file.replace(d.getVar('PKGD', True) or '', '', 1)
-        # instead is prefixed with /lib/modules/${KERNEL_VERSION}
-        file = file.replace("/lib/modules/%s/" % d.getVar('KERNEL_VERSION', True) or '', '', 1)
-
-        if file in module_deps:
-            dependencies = []
-            for i in module_deps[file]:
-                m = re.match(pattern, os.path.basename(i))
-                if not m:
-                    continue
-                on = legitimize_package_name(m.group(1))
-                dependency_pkg = format % on
-                dependencies.append(dependency_pkg)
-            return dependencies
-        return []
-
     def frob_metadata(file, pkg, pattern, format, basename):
         vals = extract_modinfo(file)
 
@@ -179,9 +117,7 @@ python split_kernel_module_packages () {
                 on = legitimize_package_name(dep)
                 dependency_pkg = format % on
                 modinfo_deps.append(dependency_pkg)
-        depmod_deps = get_dependencies(file, pattern, format)
-        all_deps = list(set(modinfo_deps + depmod_deps))
-        for dep in all_deps:
+        for dep in modinfo_deps:
             if not dep in rdepends:
                 rdepends[dep] = []
         d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends, commasep=False))
@@ -189,7 +125,6 @@ python split_kernel_module_packages () {
         # Avoid automatic -dev recommendations for modules ending with -dev.
         d.setVarFlag('RRECOMMENDS_' + pkg, 'nodeprrecs', 1)
 
-    module_deps = parse_depmod()
     module_regex = '^(.*)\.k?o$'
 
     module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX', True)
-- 
2.9.3

[PATCH v2 0/3] fixing kernel module cross-recipe dependency

[André Draszik]

Hi,

In a situation where multiple external kernel modules are built
from multiple independent recipes, we currently don't generate
correct runtime dependencies of the packages created.

This (small) series of patches attempts to address this.

It's working well for me but there'll likely be cases I haven't
considered.

v2 of this patchset:
- slightly rewords the commit message 1/3
- fixes a typo in commit message 2/3
- removes some variables that are now unused and were missed in 3/3

Cheers,
Andre'

[PATCH v2 1/3] module.bbclass: use Module.symvers for dependants

[André Draszik]

When compiling multiple external kernel modules, where one
depends on the other, there are two problems at the
moment:
1) we get compile time warnings from the kernel build
   system due to missing symbols (from modpost).
2) Any modules generated are missing dependency
   information (in the .modinfo elf section) for any
   dependencies outside the current source tree and
   outside the kernel itself.

This is expected, but the kernel build system has a way to
deal with this - the dependent module is expected to
specify KBUILD_EXTRA_SYMBOLS (as a space-separated list)
to point to any and all Module.symvers of kernel modules
that are dependencies.

While 1) by itself is not really a big issue, 2) prevents
the packaging process from generating cross-source tree
package dependencies.

As a first step to solve the missing dependencies in
packages created, we:
1) install Module.symvers of all external kernel module
   builds (into a location that is automatically packaged
   into the -dev package)
2) make use of KBUILD_EXTRA_SYMBOLS and pass the location
   of all Module.symvers of all kernel-module-* packages
   we depend on

This solves both problems mentioned above.

Signed-off-by: André Draszik <git@andred.net>
---
 meta/classes/module.bbclass | 15 +++++++++++++++
 1 file changed, 15 insertions(+)

diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
index 01c9309..68e3d34 100644
--- a/meta/classes/module.bbclass
+++ b/meta/classes/module.bbclass
@@ -8,6 +8,15 @@ EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
 
 MODULES_INSTALL_TARGET ?= "modules_install"
 
+python __anonymous () {
+    depends = d.getVar('DEPENDS', True)
+    extra_symbols = []
+    for dep in depends.split():
+        if dep.startswith("kernel-module-"):
+            extra_symbols.append("${STAGING_INCDIR}/" + dep + "/Module.symvers")
+    d.setVar('KBUILD_EXTRA_SYMBOLS', " ".join(extra_symbols))
+}
+
 module_do_compile() {
 	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
 	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
@@ -15,6 +24,7 @@ module_do_compile() {
 		   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 		   AR="${KERNEL_AR}" \
 	           O=${STAGING_KERNEL_BUILDDIR} \
+		   KBUILD_EXTRA_SYMBOLS="${KBUILD_EXTRA_SYMBOLS}" \
 		   ${MAKE_TARGETS}
 }
 
@@ -24,6 +34,11 @@ module_do_install() {
 	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
 	           O=${STAGING_KERNEL_BUILDDIR} \
 	           ${MODULES_INSTALL_TARGET}
+
+	install -d -m0755 ${D}${includedir}/${BPN}
+	cp -a --no-preserve=ownership ${B}/Module.symvers ${D}${includedir}/${BPN}
+	# it doesn't actually seem to matter which path is specified here
+	sed -e 's:${B}/::g' -i ${D}${includedir}/${BPN}/Module.symvers
 }
 
 EXPORT_FUNCTIONS do_compile do_install
-- 
2.9.3

Re: [PATCH v2 1/3] module.bbclass: use Module.symvers for dependants

[Denys Dmytriyenko]

On Thu, Aug 18, 2016 at 08:56:24AM +0100, André Draszik wrote:
> When compiling multiple external kernel modules, where one
> depends on the other, there are two problems at the
> moment:
> 1) we get compile time warnings from the kernel build
>    system due to missing symbols (from modpost).
> 2) Any modules generated are missing dependency
>    information (in the .modinfo elf section) for any
>    dependencies outside the current source tree and
>    outside the kernel itself.
> 
> This is expected, but the kernel build system has a way to
> deal with this - the dependent module is expected to
> specify KBUILD_EXTRA_SYMBOLS (as a space-separated list)
> to point to any and all Module.symvers of kernel modules
> that are dependencies.
> 
> While 1) by itself is not really a big issue, 2) prevents
> the packaging process from generating cross-source tree
> package dependencies.
> 
> As a first step to solve the missing dependencies in
> packages created, we:
> 1) install Module.symvers of all external kernel module
>    builds (into a location that is automatically packaged
>    into the -dev package)
> 2) make use of KBUILD_EXTRA_SYMBOLS and pass the location
>    of all Module.symvers of all kernel-module-* packages
>    we depend on
> 
> This solves both problems mentioned above.
> 
> Signed-off-by: André Draszik <git@andred.net>
> ---
>  meta/classes/module.bbclass | 15 +++++++++++++++
>  1 file changed, 15 insertions(+)
> 
> diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
> index 01c9309..68e3d34 100644
> --- a/meta/classes/module.bbclass
> +++ b/meta/classes/module.bbclass
> @@ -8,6 +8,15 @@ EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
>  
>  MODULES_INSTALL_TARGET ?= "modules_install"
>  
> +python __anonymous () {
> +    depends = d.getVar('DEPENDS', True)
> +    extra_symbols = []
> +    for dep in depends.split():
> +        if dep.startswith("kernel-module-"):
> +            extra_symbols.append("${STAGING_INCDIR}/" + dep + "/Module.symvers")
> +    d.setVar('KBUILD_EXTRA_SYMBOLS', " ".join(extra_symbols))
> +}
> +
>  module_do_compile() {
>  	unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>  	oe_runmake KERNEL_PATH=${STAGING_KERNEL_DIR}   \
> @@ -15,6 +24,7 @@ module_do_compile() {
>  		   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>  		   AR="${KERNEL_AR}" \
>  	           O=${STAGING_KERNEL_BUILDDIR} \
> +		   KBUILD_EXTRA_SYMBOLS="${KBUILD_EXTRA_SYMBOLS}" \
>  		   ${MAKE_TARGETS}
>  }
>  
> @@ -24,6 +34,11 @@ module_do_install() {
>  	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>  	           O=${STAGING_KERNEL_BUILDDIR} \
>  	           ${MODULES_INSTALL_TARGET}
> +
> +	install -d -m0755 ${D}${includedir}/${BPN}
> +	cp -a --no-preserve=ownership ${B}/Module.symvers ${D}${includedir}/${BPN}

Hmm, why is Module.symvers expected to be in the root of ${B}? This seems like 
a very artificial assumption/requirement!

I have some out-of-tree modules with complicated hierarchies and it worked 
fine so far until this change, because there were only 2 well defined 
interfaces - make ${MAKE_TARGETS} and make ${MODULES_INSTALL_TARGET} - and 
both of them know where the resulting module .ko resides deep inside ${B} 
hierarchy.

I wonder if this should have been rolled into ${MODULES_INSTALL_TARGET} 
step...

-- 
Denys


> +	# it doesn't actually seem to matter which path is specified here
> +	sed -e 's:${B}/::g' -i ${D}${includedir}/${BPN}/Module.symvers
>  }
>  
>  EXPORT_FUNCTIONS do_compile do_install
> -- 
> 2.9.3
> 
> -- 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [PATCH v2 1/3] module.bbclass: use Module.symvers for dependants

[André Draszik]

Hi,

On Wed, 2016-11-16 at 15:18 -0500, Denys Dmytriyenko wrote:
> On Thu, Aug 18, 2016 at 08:56:24AM +0100, André Draszik wrote:
> >  
> > @@ -24,6 +34,11 @@ module_do_install() {
> >  	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> >  	           O=${STAGING_KERNEL_BUILDDIR} \
> >  	           ${MODULES_INSTALL_TARGET}
> > +
> > +	install -d -m0755 ${D}${includedir}/${BPN}
> > +	cp -a --no-preserve=ownership ${B}/Module.symvers
> > ${D}${includedir}/${BPN}
> 
> Hmm, why is Module.symvers expected to be in the root of ${B}? This seems
> like 
> a very artificial assumption/requirement!

[...]

> I wonder if this should have been rolled into ${MODULES_INSTALL_TARGET} 
> step...

What about adding a (lazy ?=) variable to be able to override the location
of Module.symvers within ${B}, or alternatively using find to automatically
detect it? I guess there could also be more than one in theory? Do you have
something different in mind?

A.

Re: [PATCH v2 1/3] module.bbclass: use Module.symvers for dependants

[Denys Dmytriyenko]

On Thu, Nov 17, 2016 at 10:22:18AM +0000, André Draszik wrote:
> Hi,
> 
> On Wed, 2016-11-16 at 15:18 -0500, Denys Dmytriyenko wrote:
> > On Thu, Aug 18, 2016 at 08:56:24AM +0100, André Draszik wrote:
> > >  
> > > @@ -24,6 +34,11 @@ module_do_install() {
> > >  	           CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
> > >  	           O=${STAGING_KERNEL_BUILDDIR} \
> > >  	           ${MODULES_INSTALL_TARGET}
> > > +
> > > +	install -d -m0755 ${D}${includedir}/${BPN}
> > > +	cp -a --no-preserve=ownership ${B}/Module.symvers
> > > ${D}${includedir}/${BPN}
> > 
> > Hmm, why is Module.symvers expected to be in the root of ${B}? This seems
> > like 
> > a very artificial assumption/requirement!
> 
> [...]
> 
> > I wonder if this should have been rolled into ${MODULES_INSTALL_TARGET} 
> > step...
> 
> What about adding a (lazy ?=) variable to be able to override the location
> of Module.symvers within ${B}, or alternatively using find to automatically
> detect it? I guess there could also be more than one in theory? Do you have
> something different in mind?

Yes, find will probably be too ambiguous, but I like the variable idea to 
point to Module.symvers within ${B}!

For now I have a workaround to do an extra copy in do_install_prepend(), which 
is not very elegant...

-- 
Denys

[PATCH v2 2/3] kernel-module-split.bbclass: generate dependencies across recipes

[André Draszik]

The information retrieved via depmod is incomplete with
regards to kernel modules that are dependencies, in
particular where two kernel modules are built from
different source trees / recipes, which leads to incomplete
dependency information for packages created.

So far, our packages created didn't contain dependencies on
packages created by other recipes, as we solely use depmod
for that, and depmod can only work well after *all* kernel
modules have been copied into one place - it doesn't work
well in a staged approach.

Now that all .ko have correct dependency information at packaging
time, we can use that information to properly track dependencies
across recipies, and can combine the information from the
.modinfo elf section with the information from depmod.

Signed-off-by: André Draszik <git@andred.net>
---
 meta/classes/kernel-module-split.bbclass | 10 +++++++++-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index ed42d2b..db0ad33 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -173,7 +173,15 @@ python split_kernel_module_packages () {
             d.setVar('DESCRIPTION_' + pkg, old_desc + "; " + vals["description"])
 
         rdepends = bb.utils.explode_dep_versions2(d.getVar('RDEPENDS_' + pkg, True) or "")
-        for dep in get_dependencies(file, pattern, format):
+        modinfo_deps = []
+        if "depends" in vals and vals["depends"] != "":
+            for dep in vals["depends"].split(","):
+                on = legitimize_package_name(dep)
+                dependency_pkg = format % on
+                modinfo_deps.append(dependency_pkg)
+        depmod_deps = get_dependencies(file, pattern, format)
+        all_deps = list(set(modinfo_deps + depmod_deps))
+        for dep in all_deps:
             if not dep in rdepends:
                 rdepends[dep] = []
         d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends, commasep=False))
-- 
2.9.3

[PATCH v2 3/3] kernel-module-split.bbclass: no need for running depmod

[André Draszik]

With the recent changes, executing depmod is not needed
anymore.

This simplifies and removes a lot of unnecessary code.

Signed-off-by: André Draszik <git@andred.net>
---
 meta/classes/kernel-module-split.bbclass | 73 +-------------------------------
 1 file changed, 1 insertion(+), 72 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass b/meta/classes/kernel-module-split.bbclass
index db0ad33..08d2262 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -36,12 +36,6 @@ python split_kernel_module_packages () {
     import re
 
     modinfoexp = re.compile("([^=]+)=(.*)")
-    kerverrexp = re.compile('^(.*-hh.*)[\.\+].*$')
-    depmodpat0 = re.compile("^(.*\.k?o):..*$")
-    depmodpat1 = re.compile("^(.*\.k?o):\s*(.*\.k?o)\s*$")
-    depmodpat2 = re.compile("^(.*\.k?o):\s*(.*\.k?o)\s*\\\$")
-    depmodpat3 = re.compile("^\t(.*\.k?o)\s*\\\$")
-    depmodpat4 = re.compile("^\t(.*\.k?o)\s*$")
 
     def extract_modinfo(file):
         import tempfile, subprocess
@@ -63,68 +57,6 @@ python split_kernel_module_packages () {
             vals[m.group(1)] = m.group(2)
         return vals
 
-    def parse_depmod():
-
-        dvar = d.getVar('PKGD', True)
-
-        kernelver = d.getVar('KERNEL_VERSION', True)
-        kernelver_stripped = kernelver
-        m = kerverrexp.match(kernelver)
-        if m:
-            kernelver_stripped = m.group(1)
-        staging_kernel_dir = d.getVar("STAGING_KERNEL_BUILDDIR", True)
-        system_map_file = "%s/boot/System.map-%s" % (dvar, kernelver)
-        if not os.path.exists(system_map_file):
-            system_map_file = "%s/System.map-%s" % (staging_kernel_dir, kernelver)
-            if not os.path.exists(system_map_file):
-                bb.fatal("System.map-%s does not exist in '%s/boot' nor STAGING_KERNEL_BUILDDIR '%s'" % (kernelver, dvar, staging_kernel_dir))
-
-        cmd = "depmod -n -a -b %s -F %s %s" % (dvar, system_map_file, kernelver_stripped)
-        f = os.popen(cmd, 'r')
-
-        deps = {}
-        line = f.readline()
-        while line:
-            if not depmodpat0.match(line):
-                line = f.readline()
-                continue
-            m1 = depmodpat1.match(line)
-            if m1:
-                deps[m1.group(1)] = m1.group(2).split()
-            else:
-                m2 = depmodpat2.match(line)
-                if m2:
-                    deps[m2.group(1)] = m2.group(2).split()
-                    line = f.readline()
-                    m3 = depmodpat3.match(line)
-                    while m3:
-                        deps[m2.group(1)].extend(m3.group(1).split())
-                        line = f.readline()
-                        m3 = depmodpat3.match(line)
-                    m4 = depmodpat4.match(line)
-                    deps[m2.group(1)].extend(m4.group(1).split())
-            line = f.readline()
-        f.close()
-        return deps
-
-    def get_dependencies(file, pattern, format):
-        # file no longer includes PKGD
-        file = file.replace(d.getVar('PKGD', True) or '', '', 1)
-        # instead is prefixed with /lib/modules/${KERNEL_VERSION}
-        file = file.replace("/lib/modules/%s/" % d.getVar('KERNEL_VERSION', True) or '', '', 1)
-
-        if file in module_deps:
-            dependencies = []
-            for i in module_deps[file]:
-                m = re.match(pattern, os.path.basename(i))
-                if not m:
-                    continue
-                on = legitimize_package_name(m.group(1))
-                dependency_pkg = format % on
-                dependencies.append(dependency_pkg)
-            return dependencies
-        return []
-
     def frob_metadata(file, pkg, pattern, format, basename):
         vals = extract_modinfo(file)
 
@@ -179,9 +111,7 @@ python split_kernel_module_packages () {
                 on = legitimize_package_name(dep)
                 dependency_pkg = format % on
                 modinfo_deps.append(dependency_pkg)
-        depmod_deps = get_dependencies(file, pattern, format)
-        all_deps = list(set(modinfo_deps + depmod_deps))
-        for dep in all_deps:
+        for dep in modinfo_deps:
             if not dep in rdepends:
                 rdepends[dep] = []
         d.setVar('RDEPENDS_' + pkg, bb.utils.join_deps(rdepends, commasep=False))
@@ -189,7 +119,6 @@ python split_kernel_module_packages () {
         # Avoid automatic -dev recommendations for modules ending with -dev.
         d.setVarFlag('RRECOMMENDS_' + pkg, 'nodeprrecs', 1)
 
-    module_deps = parse_depmod()
     module_regex = '^(.*)\.k?o$'
 
     module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX', True)
-- 
2.9.3

Re: [PATCH v2 0/3] fixing kernel module cross-recipe dependency

[André Draszik]

On Do, 2016-08-18 at 08:56 +0100, André Draszik wrote:
> In a situation where multiple external kernel modules are built
> from multiple independent recipes, we currently don't generate
> correct runtime dependencies of the packages created.
> 
> This (small) series of patches attempts to address this.

Is there anything wrong with these patches?


Cheers,
Andre'

Re: [PATCH v2 0/3] fixing kernel module cross-recipe dependency

[André Draszik]

On Fr, 2016-08-26 at 11:38 +0100, André Draszik wrote:
> On Do, 2016-08-18 at 08:56 +0100, André Draszik wrote:
> > 
> > In a situation where multiple external kernel modules are built
> > from multiple independent recipes, we currently don't generate
> > correct runtime dependencies of the packages created.
> > 
> > This (small) series of patches attempts to address this.
> 
> Is there anything wrong with these patches?

I don't want to be rude, just in case this series ended up under the radar,
I'm asking again :-)

a.