Re: [OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

2017-08-15 Thread Wold, Saul 
On Mon, 2017-08-14 at 16:29 -0500, Haris Okanovic wrote:
> 
> On 08/08/2017 05:33 PM, Wold, Saul wrote:
> > 
> > On Tue, 2017-08-08 at 10:30 -0500, Haris Okanovic wrote:
> > > 
> > > Some distros may want to provide alternate kernel "flavors" via
> > > feeds
> > > or
> > > within bootable images. For example, readily available builds
> > > which
> > > provide certain diagnostic features can enable developers and
> > > testers
> > > to
> > > more quickly resolve issues by avoiding lengthy kernel builds.
> > > 
> > > This change allows for building multiple flavors of the kernel
> > > and
> > > module packages by templatizing kernel package names via a new
> > > KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to
> > > the
> > > old
> > > name of "kernel", but can be overridden by certain recipes
> > > providing
> > > alternate kernel flavors.
> > > 
> > > To maintain compatibility, recipes providing alternate kernel
> > > flavors
> > > cannot be the "preferred provider" for virtual/kernel. This is
> > > because
> > > OE puts the preferred provider's build and source at
> > > "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> > > "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> > > "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes
> > > using
> > > the
> > > default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> > > build
> > > in the old location and may be preferred provider -- while
> > > recipes
> > > using
> > > all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> > > don't
> > > provide "virtual/kernel".
> > > 
> > > Testing:
> > >   1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> > >  linux-yocto-tiny_4.9.bb so that it may build alongside
> > >  the main kernel.
> > >   2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> > > flavors.
> > >   3. Verified image and modules IPKs exist for both:
> > >  tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> > >  tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-
> > > tiny
> > >   4. Verified linux-yocto is the "preferred provider", and was
> > > built
> > > in
> > >  shared directory: tmp-glibc/work-shared/qemux86/kernel-*
> > >   5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> > >  core-image-base.bb to include both kernel flavors.
> > >   6. `bitbake core-image-base` to build an image.
> > >   7. Verified image contains two bzImage's under /boot/, with
> > >  "yocto-standard" selected to boot via symlink.
> > > 
> > Thank you for continuing to work on this.  I did a simple test of
> > building a single kernel and lttng-modules without your change and
> > then
> > added this patch and tried lttng-modules with no additional changes
> > to
> > my local.conf, just regular single kernel workflow.
> > 
> > I got the following issue:
> > 
> > ERROR: lttng-modules-2.9.3-r0 do_package: Error executing a python
> > function in exec_python_func() autogenerated:
> > 
> > The stack trace of python calls that resulted in this
> > exception/failure
> > was:
> > File: 'exec_python_func() autogenerated', lineno: 2, function:
> > 
> >   0001:
> >   *** 0002:split_kernel_module_packages(d)
> >   0003:
> > File: '/srv/sdb/releases/master/meta/classes/kernel-module-
> > split.bbclass', lineno: 139, function: split_kernel_module_packages
> >   0135:module_regex = '^(.*)\.k?o$'
> >   0136:
> >   0137:module_pattern_prefix =
> > d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
> >   0138:module_pattern_suffix =
> > d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
> >   *** 0139:module_pattern = module_pattern_prefix +
> > kernel_package_name + '-module-%s' + module_pattern_suffix
> >   0140:
> >   0141:postinst = d.getVar('pkg_postinst_modules')
> >   0142:postrm = d.getVar('pkg_postrm_modules')
> >   0143:
> > Exception: TypeError: Can't convert 'NoneType' object to str
> > implicitly
> > 
> > ERROR: lttng-modules-2.9.3-r0 do_package: Function failed:
> > split_kernel_module_packages
> > ERROR: Logfile of failure stored in:
> > /srv/sdb/releases/master/builds/corei7/tmp/work/genericx86_64-poky-
> > linux/lttng-modules/2.9.3-r0/temp/log.do_package.80115
> > NOTE: recipe lttng-modules-2.9.3-r0: task do_package: Failed
> > 
> > I believe the problem is that I tried to build lttng-modules
> > standalone
> > and so the kernel.bbclass does not get involved to set the
> > KERNEL_PACKAGE_NAME default.
> > 
> 
> Correct. I mistakenly though everything relating to kernel builds 
> sources kernel.bbclass.
> 
> I added a default KERNEL_PACKAGE_NAME to kernel-module-
> split.bbclass, 
> for the module-only case. However, I'm not sure if there's a better 
> place for it. Thoughts? (PATCH v6 incoming)
> 
I think the better idea might be to put in a check if it's not set then
use the default value of kernel, rather than adding another default
setting of KERNEL_PACKAGE_NAME, since that variable will be

Re: [OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

2017-08-14 Thread Haris Okanovic 



On 08/08/2017 05:33 PM, Wold, Saul wrote:

On Tue, 2017-08-08 at 10:30 -0500, Haris Okanovic wrote:

Some distros may want to provide alternate kernel "flavors" via feeds
or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers
to
more quickly resolve issues by avoiding lengthy kernel builds.

This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.

To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is
because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
build
in the old location and may be preferred provider -- while recipes
using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
don't
provide "virtual/kernel".

Testing:
  1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
 linux-yocto-tiny_4.9.bb so that it may build alongside
 the main kernel.
  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
flavors.
  3. Verified image and modules IPKs exist for both:
 tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
 tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
  4. Verified linux-yocto is the "preferred provider", and was built
in
 shared directory: tmp-glibc/work-shared/qemux86/kernel-*
  5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
 core-image-base.bb to include both kernel flavors.
  6. `bitbake core-image-base` to build an image.
  7. Verified image contains two bzImage's under /boot/, with
 "yocto-standard" selected to boot via symlink.


Thank you for continuing to work on this.  I did a simple test of
building a single kernel and lttng-modules without your change and then
added this patch and tried lttng-modules with no additional changes to
my local.conf, just regular single kernel workflow.

I got the following issue:

ERROR: lttng-modules-2.9.3-r0 do_package: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
  0001:
  *** 0002:split_kernel_module_packages(d)
  0003:
File: '/srv/sdb/releases/master/meta/classes/kernel-module-
split.bbclass', lineno: 139, function: split_kernel_module_packages
  0135:module_regex = '^(.*)\.k?o$'
  0136:
  0137:module_pattern_prefix =
d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
  0138:module_pattern_suffix =
d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
  *** 0139:module_pattern = module_pattern_prefix +
kernel_package_name + '-module-%s' + module_pattern_suffix
  0140:
  0141:postinst = d.getVar('pkg_postinst_modules')
  0142:postrm = d.getVar('pkg_postrm_modules')
  0143:
Exception: TypeError: Can't convert 'NoneType' object to str implicitly

ERROR: lttng-modules-2.9.3-r0 do_package: Function failed:
split_kernel_module_packages
ERROR: Logfile of failure stored in:
/srv/sdb/releases/master/builds/corei7/tmp/work/genericx86_64-poky-
linux/lttng-modules/2.9.3-r0/temp/log.do_package.80115
NOTE: recipe lttng-modules-2.9.3-r0: task do_package: Failed

I believe the problem is that I tried to build lttng-modules standalone
and so the kernel.bbclass does not get involved to set the
KERNEL_PACKAGE_NAME default.



Correct. I mistakenly though everything relating to kernel builds 
sources kernel.bbclass.


I added a default KERNEL_PACKAGE_NAME to kernel-module-split.bbclass, 
for the module-only case. However, I'm not sure if there's a better 
place for it. Thoughts? (PATCH v6 incoming)



I see that your procedure above works for.

Thanks again for your work, sorry I am finding interesting issues
still.



Np. I'm glad we're resolving all these issues up front instead of 
dealing with a pile of bug reports!



Sau!



Discussion thread:
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openembedded.org_pipermail_openembedded-2Dcore_2015-2DDecemb=DwIGaQ=I_0YwoKy7z5LMTVdyO6YCiE2uzI1jjZZuIPelcSjixA=8Bziuw3IaCGjyrSAphuGwHmVdHcVwza-srUYwL9U_Ms=iuC18jvFNmy37KjmclOXXAfHiXfxfSi5MfqscPB9ips=IkiycfArbVDluMaryQbZLW8sYavV651AD-nHbJYSXEw=
er/thread.html#114122

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Gratian Crisan 
Signed-off-by: Haris Okanovic 
Coauthored-by: Gratian Crisan 
Coauthored-by: Haris Okanovic

Re: [OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

2017-08-08 Thread Wold, Saul 
On Tue, 2017-08-08 at 10:30 -0500, Haris Okanovic wrote:
> Some distros may want to provide alternate kernel "flavors" via feeds
> or
> within bootable images. For example, readily available builds which
> provide certain diagnostic features can enable developers and testers
> to
> more quickly resolve issues by avoiding lengthy kernel builds.
> 
> This change allows for building multiple flavors of the kernel and
> module packages by templatizing kernel package names via a new
> KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the
> old
> name of "kernel", but can be overridden by certain recipes providing
> alternate kernel flavors.
> 
> To maintain compatibility, recipes providing alternate kernel flavors
> cannot be the "preferred provider" for virtual/kernel. This is
> because
> OE puts the preferred provider's build and source at
> "tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
> "tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
> "tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using
> the
> default KERNEL_PACKAGE_NAME="kernel" follows the old semantics --
> build
> in the old location and may be preferred provider -- while recipes
> using
> all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and
> don't
> provide "virtual/kernel".
> 
> Testing:
>  1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
> linux-yocto-tiny_4.9.bb so that it may build alongside
> the main kernel.
>  2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel
> flavors.
>  3. Verified image and modules IPKs exist for both:
> tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
> tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
>  4. Verified linux-yocto is the "preferred provider", and was built
> in
> shared directory: tmp-glibc/work-shared/qemux86/kernel-*
>  5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
> core-image-base.bb to include both kernel flavors.
>  6. `bitbake core-image-base` to build an image.
>  7. Verified image contains two bzImage's under /boot/, with
> "yocto-standard" selected to boot via symlink.
> 
Thank you for continuing to work on this.  I did a simple test of
building a single kernel and lttng-modules without your change and then
added this patch and tried lttng-modules with no additional changes to
my local.conf, just regular single kernel workflow.

I got the following issue:

ERROR: lttng-modules-2.9.3-r0 do_package: Error executing a python
function in exec_python_func() autogenerated:

The stack trace of python calls that resulted in this exception/failure
was:
File: 'exec_python_func() autogenerated', lineno: 2, function: 
 0001:
 *** 0002:split_kernel_module_packages(d)
 0003:
File: '/srv/sdb/releases/master/meta/classes/kernel-module-
split.bbclass', lineno: 139, function: split_kernel_module_packages
 0135:module_regex = '^(.*)\.k?o$'
 0136:
 0137:module_pattern_prefix =
d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 0138:module_pattern_suffix =
d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
 *** 0139:module_pattern = module_pattern_prefix +
kernel_package_name + '-module-%s' + module_pattern_suffix
 0140:
 0141:postinst = d.getVar('pkg_postinst_modules')
 0142:postrm = d.getVar('pkg_postrm_modules')
 0143:
Exception: TypeError: Can't convert 'NoneType' object to str implicitly

ERROR: lttng-modules-2.9.3-r0 do_package: Function failed:
split_kernel_module_packages
ERROR: Logfile of failure stored in:
/srv/sdb/releases/master/builds/corei7/tmp/work/genericx86_64-poky-
linux/lttng-modules/2.9.3-r0/temp/log.do_package.80115
NOTE: recipe lttng-modules-2.9.3-r0: task do_package: Failed

I believe the problem is that I tried to build lttng-modules standalone
and so the kernel.bbclass does not get involved to set the
KERNEL_PACKAGE_NAME default.

I see that your procedure above works for.

Thanks again for your work, sorry I am finding interesting issues
still.

Sau!


> Discussion thread:
> http://lists.openembedded.org/pipermail/openembedded-core/2015-Decemb
> er/thread.html#114122
> 
> Signed-off-by: Ioan-Adrian Ratiu 
> Signed-off-by: Gratian Crisan 
> Signed-off-by: Haris Okanovic 
> Coauthored-by: Gratian Crisan 
> Coauthored-by: Haris Okanovic 
> Coauthored-by: Josh Hernstrom 
> ---
> [PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to
> the
> "work" directory in alternate kernel builds, instead of "work-
> shared",
> so
> that the two builds don't clobber each other.
> 
> [PATCH v3] An updated version of this change rebased onto the current
> OE-core master. Changes:
>  - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
>    kernel builds, since alternate kernels aren't the
>    PREFERRED_PROVIDER for virtual/kernel by definition.
>  - Remove

[OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

2017-08-08 Thread Haris Okanovic 
Some distros may want to provide alternate kernel "flavors" via feeds or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers to
more quickly resolve issues by avoiding lengthy kernel builds.

This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.

To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build
in the old location and may be preferred provider -- while recipes using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't
provide "virtual/kernel".

Testing:
 1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
linux-yocto-tiny_4.9.bb so that it may build alongside
the main kernel.
 2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors.
 3. Verified image and modules IPKs exist for both:
tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
 4. Verified linux-yocto is the "preferred provider", and was built in
shared directory: tmp-glibc/work-shared/qemux86/kernel-*
 5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
core-image-base.bb to include both kernel flavors.
 6. `bitbake core-image-base` to build an image.
 7. Verified image contains two bzImage's under /boot/, with
"yocto-standard" selected to boot via symlink.

Discussion thread:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Gratian Crisan 
Signed-off-by: Haris Okanovic 
Coauthored-by: Gratian Crisan 
Coauthored-by: Haris Okanovic 
Coauthored-by: Josh Hernstrom 
---
[PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to the
"work" directory in alternate kernel builds, instead of "work-shared",
so
that the two builds don't clobber each other.

[PATCH v3] An updated version of this change rebased onto the current
OE-core master. Changes:
 - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
   kernel builds, since alternate kernels aren't the
   PREFERRED_PROVIDER for virtual/kernel by definition.
 - Remove "virtual/kernel" from PROVIDES in alternate kernel builds.

[PATCH v4] Another rebase onto master; no functional change.
Improved description and testing steps.

[PATCH v5]
 - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
 - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions

https://github.com/harisokanovic/openembedded-core/tree/dev/hokanovi/multi-kernel-packages-v5
---
 meta/classes/kernel-module-split.bbclass  |   9 ++-
 meta/classes/kernel.bbclass   | 114 +++---
 meta/conf/documentation.conf  |   1 +
 meta/recipes-kernel/linux/linux-dtb.inc   |   2 +-
 meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
 5 files changed, 81 insertions(+), 47 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 1035525dac..9716c5937b 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -30,7 +30,7 @@ do_install_append() {
 
 PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
 
-KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
+KERNEL_MODULES_META_PACKAGE ?= "${KERNEL_PACKAGE_NAME}-modules"
 
 KERNEL_MODULE_PACKAGE_PREFIX ?= ""
 KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
@@ -129,16 +129,19 @@ python split_kernel_module_packages () {
postfix = format.split('%s')[1]
d.setVar('RPROVIDES_' + pkg, pkg.replace(postfix, ''))
 
+kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME", True)
+kernel_version = d.getVar("KERNEL_VERSION", True)
+
 module_regex = '^(.*)\.k?o$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
-module_pattern = module_pattern_prefix + 'kernel-module-%s' + 
module_pattern_suffix
+module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
 postinst = d.getVar('pkg_postinst_modules')
 postrm = d.getVar('pkg_postrm_modules')
 
-modules = do_split_packages(d,

[OE-core] [PATCH v5] kernel: Add support for multiple kernel packages

2017-08-08 Thread Haris Okanovic 
Some distros may want to provide alternate kernel "flavors" via feeds or
within bootable images. For example, readily available builds which
provide certain diagnostic features can enable developers and testers to
more quickly resolve issues by avoiding lengthy kernel builds.

This change allows for building multiple flavors of the kernel and
module packages by templatizing kernel package names via a new
KERNEL_PACKAGE_NAME variable in kernel.bbclass. It defaults to the old
name of "kernel", but can be overridden by certain recipes providing
alternate kernel flavors.

To maintain compatibility, recipes providing alternate kernel flavors
cannot be the "preferred provider" for virtual/kernel. This is because
OE puts the preferred provider's build and source at
"tmp-glibc/work-shared/$MACHINE/kernel-build-artifacts/" and
"tmp-glibc/work-shared/$MACHINE/kernel-source/" instead of
"tmp-glibc/work/*/$PN/" like other recipes. Therefore, recipes using the
default KERNEL_PACKAGE_NAME="kernel" follows the old semantics -- build
in the old location and may be preferred provider -- while recipes using
all other KERNEL_PACKAGE_NAME's build from the normal WORKDIR and don't
provide "virtual/kernel".

Testing:
 1. Prepended `KERNEL_PACKAGE_NAME = "tiny-linux"` to
linux-yocto-tiny_4.9.bb so that it may build alongside
the main kernel.
 2. `bitbake linux-yocto linux-yocto-tiny` to build both kernel flavors.
 3. Verified image and modules IPKs exist for both:
tmp-glibc/deploy/ipk/qemux86/kernel-* for linux-yocto
tmp-glibc/deploy/ipk/qemux86/tiny-linux* for linux-yocto-tiny
 4. Verified linux-yocto is the "preferred provider", and was built in
shared directory: tmp-glibc/work-shared/qemux86/kernel-*
 5. Appended `CORE_IMAGE_BASE_INSTALL += "tiny-linux"` to
core-image-base.bb to include both kernel flavors.
 6. `bitbake core-image-base` to build an image.
 7. Verified image contains two bzImage's under /boot/, with
"yocto-standard" selected to boot via symlink.

Discussion thread:
http://lists.openembedded.org/pipermail/openembedded-core/2015-December/thread.html#114122

Signed-off-by: Ioan-Adrian Ratiu 
Signed-off-by: Gratian Crisan 
Signed-off-by: Haris Okanovic 
Coauthored-by: Gratian Crisan 
Coauthored-by: Haris Okanovic 
Coauthored-by: Josh Hernstrom 
---
[PATCH v2] Change STAGING_KERNEL_DIR and STAGING_KERNEL_BUILDDIR to the
"work" directory in alternate kernel builds, instead of "work-shared",
so
that the two builds don't clobber each other.

[PATCH v3] An updated version of this change rebased onto the current
OE-core master. Changes:
 - Remove PREFERRED_PROVIDER check in linux-yocto.inc in alternate
   kernel builds, since alternate kernels aren't the
   PREFERRED_PROVIDER for virtual/kernel by definition.
 - Remove "virtual/kernel" from PROVIDES in alternate kernel builds.

[PATCH v4] Another rebase onto master; no functional change.
Improved description and testing steps.

[PATCH v5]
 - Warn when PN == KERNEL_PACKAGE_NAME (bug # 11905)
 - Add KERNEL_DEPLOYSUBDIR to avoid DEPLOYDIR collisions

https://github.com/harisokanovic/openembedded-core/tree/dev/hokanovi/multi-kernel-packages-v5
---
 meta/classes/kernel-module-split.bbclass  |   9 ++-
 meta/classes/kernel.bbclass   | 114 +++---
 meta/conf/documentation.conf  |   1 +
 meta/recipes-kernel/linux/linux-dtb.inc   |   2 +-
 meta/recipes-kernel/linux/linux-yocto.inc |   2 +-
 5 files changed, 81 insertions(+), 47 deletions(-)

diff --git a/meta/classes/kernel-module-split.bbclass 
b/meta/classes/kernel-module-split.bbclass
index 1035525dac..9716c5937b 100644
--- a/meta/classes/kernel-module-split.bbclass
+++ b/meta/classes/kernel-module-split.bbclass
@@ -30,7 +30,7 @@ do_install_append() {
 
 PACKAGESPLITFUNCS_prepend = "split_kernel_module_packages "
 
-KERNEL_MODULES_META_PACKAGE ?= "kernel-modules"
+KERNEL_MODULES_META_PACKAGE ?= "${KERNEL_PACKAGE_NAME}-modules"
 
 KERNEL_MODULE_PACKAGE_PREFIX ?= ""
 KERNEL_MODULE_PACKAGE_SUFFIX ?= "-${KERNEL_VERSION}"
@@ -129,16 +129,19 @@ python split_kernel_module_packages () {
postfix = format.split('%s')[1]
d.setVar('RPROVIDES_' + pkg, pkg.replace(postfix, ''))
 
+kernel_package_name = d.getVar("KERNEL_PACKAGE_NAME", True)
+kernel_version = d.getVar("KERNEL_VERSION", True)
+
 module_regex = '^(.*)\.k?o$'
 
 module_pattern_prefix = d.getVar('KERNEL_MODULE_PACKAGE_PREFIX')
 module_pattern_suffix = d.getVar('KERNEL_MODULE_PACKAGE_SUFFIX')
-module_pattern = module_pattern_prefix + 'kernel-module-%s' + 
module_pattern_suffix
+module_pattern = module_pattern_prefix + kernel_package_name + 
'-module-%s' + module_pattern_suffix
 
 postinst = d.getVar('pkg_postinst_modules')
 postrm = d.getVar('pkg_postrm_modules')
 
-modules = do_split_packages(d,