* Revert kernel-moudle- workaround for out-of-tree module package
@ 2013-08-14 16:41 Yang Shi
2013-08-14 16:41 ` [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" Yang Shi
0 siblings, 1 reply; 5+ messages in thread
From: Yang Shi @ 2013-08-14 16:41 UTC (permalink / raw)
To: openembedded-core; +Cc: dvhart
The package runtime mapping rename issue is already fixed by
commit 0bc564af07c1bae8112f834a60aea3b72af7de13, the "kernel-module-" workaround
is not necessary anymore for out-of-tree module package, so revert that commit.
Yang Shi (1):
Revert "hello-mod: Ensure the produced package name begins with kernel-module-"
.../recipes-kernel/hello-mod/hello-mod_0.1.bb | 8 --------
1 files changed, 0 insertions(+), 8 deletions(-)
^ permalink raw reply [flat|nested] 5+ messages in thread* [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" 2013-08-14 16:41 Revert kernel-moudle- workaround for out-of-tree module package Yang Shi @ 2013-08-14 16:41 ` Yang Shi 2013-08-14 18:10 ` Darren Hart 0 siblings, 1 reply; 5+ messages in thread From: Yang Shi @ 2013-08-14 16:41 UTC (permalink / raw) To: openembedded-core; +Cc: dvhart [YOCTO #4286] The package runtime mapping rename issue is already fixed by commit 0bc564af07c1bae8112f834a60aea3b72af7de13, the "kernel-module-" workaround is not necessary anymore for out-of-tree module package, so revert that commit. This reverts commit 71aafc214fe407b7620e747c11dfb8326c867b1c. Signed-off-by: Yang Shi <yang.shi@windriver.com> --- .../recipes-kernel/hello-mod/hello-mod_0.1.bb | 8 -------- 1 files changed, 0 insertions(+), 8 deletions(-) diff --git a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb index 621f700..64a6dda 100644 --- a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb +++ b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb @@ -13,11 +13,3 @@ SRC_URI = "file://Makefile \ " S = "${WORKDIR}" - -# Kernel module packages MUST begin with 'kernel-module-', otherwise -# multilib image generation can fail. -# -# The following line is only necessary if the recipe name does not begin -# with kernel-module-. -# -PKG_${PN} = "kernel-module-${PN}" -- 1.7.5.4 ^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" 2013-08-14 16:41 ` [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" Yang Shi @ 2013-08-14 18:10 ` Darren Hart 2013-08-14 18:35 ` Mark Hatle 0 siblings, 1 reply; 5+ messages in thread From: Darren Hart @ 2013-08-14 18:10 UTC (permalink / raw) To: Yang Shi; +Cc: openembedded-core On Wed, 2013-08-14 at 09:41 -0700, Yang Shi wrote: > [YOCTO #4286] > > The package runtime mapping rename issue is already fixed by > commit 0bc564af07c1bae8112f834a60aea3b72af7de13, the "kernel-module-" workaround > is not necessary anymore for out-of-tree module package, so revert that commit. > > This reverts commit 71aafc214fe407b7620e747c11dfb8326c867b1c. > Is runtime mapping rename the right solution to this? I don't have any experience with it, I'm not objecting, just asking the question. Is runtime mapping rename a catchall for things that don't do the right thing in the first place, or is it the preferred mechanism? My uninformed initial reaction is that it makes more sense to be explicit with this sort of thing so people can know what to expect as the output from recipes like this without having to track down what the runtime mapping rename will do to the package output. As things stand now, I can see from the hello-mod recipe that the package will be called kernel-module-hello-mod, if we drop this, I would expect it to be hello-mod if I didn't have a deep knowledge of this rename mechanism... My 0.02 USD. > Signed-off-by: Yang Shi <yang.shi@windriver.com> > --- > .../recipes-kernel/hello-mod/hello-mod_0.1.bb | 8 -------- > 1 files changed, 0 insertions(+), 8 deletions(-) > > diff --git a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb > index 621f700..64a6dda 100644 > --- a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb > +++ b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb > @@ -13,11 +13,3 @@ SRC_URI = "file://Makefile \ > " > > S = "${WORKDIR}" > - > -# Kernel module packages MUST begin with 'kernel-module-', otherwise > -# multilib image generation can fail. > -# > -# The following line is only necessary if the recipe name does not begin > -# with kernel-module-. > -# > -PKG_${PN} = "kernel-module-${PN}" -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" 2013-08-14 18:10 ` Darren Hart @ 2013-08-14 18:35 ` Mark Hatle 2013-08-16 15:23 ` Yang Shi 0 siblings, 1 reply; 5+ messages in thread From: Mark Hatle @ 2013-08-14 18:35 UTC (permalink / raw) To: Darren Hart; +Cc: openembedded-core On 8/14/13 1:10 PM, Darren Hart wrote: > On Wed, 2013-08-14 at 09:41 -0700, Yang Shi wrote: >> [YOCTO #4286] >> >> The package runtime mapping rename issue is already fixed by >> commit 0bc564af07c1bae8112f834a60aea3b72af7de13, the "kernel-module-" workaround >> is not necessary anymore for out-of-tree module package, so revert that commit. >> >> This reverts commit 71aafc214fe407b7620e747c11dfb8326c867b1c. >> > > Is runtime mapping rename the right solution to this? I don't have any > experience with it, I'm not objecting, just asking the question. Is > runtime mapping rename a catchall for things that don't do the right > thing in the first place, or is it the preferred mechanism? There we two patches that went into the main oe-core that make this change no longer relevant. The first is a change 51928b6b5ca0a46a9dcd754483a19af58b95fa18, by Martin Jansa. This automatically adds the kernel-module- prefix to kernel module packages. The second was the recent commit 0bc564af07c1bae8112f834a60aea3b72af7de13 that allowed this change to work in a multilib environment. To keep the example being as 'clean' as possible, we want to revert the workaround as it is no longer needed. > My uninformed initial reaction is that it makes more sense to be > explicit with this sort of thing so people can know what to expect as > the output from recipes like this without having to track down what the > runtime mapping rename will do to the package output. The initial bug and feature request was that users creating packages that provide kernel-modules shouldn't have to know they need 'kernel-module-' in the name. (Without that there are numerous QA and other checks that fail, some in ways that make it hard to figure out what went wrong.) > As things stand now, I can see from the hello-mod recipe that the > package will be called kernel-module-hello-mod, if we drop this, I would > expect it to be hello-mod if I didn't have a deep knowledge of this > rename mechanism... Perhaps the need then is to document that the inherit of the modules bbclass will automatically name module packages w/ kernel-module- as required by the oe-core build environment? > My 0.02 USD. > >> Signed-off-by: Yang Shi <yang.shi@windriver.com> >> --- >> .../recipes-kernel/hello-mod/hello-mod_0.1.bb | 8 -------- >> 1 files changed, 0 insertions(+), 8 deletions(-) >> >> diff --git a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >> index 621f700..64a6dda 100644 >> --- a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >> +++ b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >> @@ -13,11 +13,3 @@ SRC_URI = "file://Makefile \ >> " >> >> S = "${WORKDIR}" >> - >> -# Kernel module packages MUST begin with 'kernel-module-', otherwise >> -# multilib image generation can fail. >> -# >> -# The following line is only necessary if the recipe name does not begin >> -# with kernel-module-. >> -# >> -PKG_${PN} = "kernel-module-${PN}" > ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" 2013-08-14 18:35 ` Mark Hatle @ 2013-08-16 15:23 ` Yang Shi 0 siblings, 0 replies; 5+ messages in thread From: Yang Shi @ 2013-08-16 15:23 UTC (permalink / raw) To: Mark Hatle; +Cc: Darren Hart, openembedded-core On 8/14/2013 11:35 AM, Mark Hatle wrote: > On 8/14/13 1:10 PM, Darren Hart wrote: >> On Wed, 2013-08-14 at 09:41 -0700, Yang Shi wrote: >>> [YOCTO #4286] >>> >>> The package runtime mapping rename issue is already fixed by >>> commit 0bc564af07c1bae8112f834a60aea3b72af7de13, the >>> "kernel-module-" workaround >>> is not necessary anymore for out-of-tree module package, so revert >>> that commit. >>> >>> This reverts commit 71aafc214fe407b7620e747c11dfb8326c867b1c. >>> >> >> Is runtime mapping rename the right solution to this? I don't have any >> experience with it, I'm not objecting, just asking the question. Is >> runtime mapping rename a catchall for things that don't do the right >> thing in the first place, or is it the preferred mechanism? > > There we two patches that went into the main oe-core that make this > change no longer relevant. The first is a change > 51928b6b5ca0a46a9dcd754483a19af58b95fa18, by Martin Jansa. This > automatically adds the kernel-module- prefix to kernel module packages. > > The second was the recent commit > 0bc564af07c1bae8112f834a60aea3b72af7de13 that allowed this change to > work in a multilib environment. To keep the example being as 'clean' > as possible, we want to revert the workaround as it is no longer needed. > >> My uninformed initial reaction is that it makes more sense to be >> explicit with this sort of thing so people can know what to expect as >> the output from recipes like this without having to track down what the >> runtime mapping rename will do to the package output. > > The initial bug and feature request was that users creating packages > that provide kernel-modules shouldn't have to know they need > 'kernel-module-' in the name. (Without that there are numerous QA and > other checks that fail, some in ways that make it hard to figure out > what went wrong.) > >> As things stand now, I can see from the hello-mod recipe that the >> package will be called kernel-module-hello-mod, if we drop this, I would >> expect it to be hello-mod if I didn't have a deep knowledge of this >> rename mechanism... > > Perhaps the need then is to document that the inherit of the modules > bbclass will automatically name module packages w/ kernel-module- as > required by the oe-core build environment? Any further comment on this? So, per Mark's comment, this workaround makes no sense so we should revert it. Thanks, Yang > >> My 0.02 USD. >> >>> Signed-off-by: Yang Shi <yang.shi@windriver.com> >>> --- >>> .../recipes-kernel/hello-mod/hello-mod_0.1.bb | 8 -------- >>> 1 files changed, 0 insertions(+), 8 deletions(-) >>> >>> diff --git a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >>> b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >>> index 621f700..64a6dda 100644 >>> --- a/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >>> +++ b/meta-skeleton/recipes-kernel/hello-mod/hello-mod_0.1.bb >>> @@ -13,11 +13,3 @@ SRC_URI = "file://Makefile \ >>> " >>> >>> S = "${WORKDIR}" >>> - >>> -# Kernel module packages MUST begin with 'kernel-module-', otherwise >>> -# multilib image generation can fail. >>> -# >>> -# The following line is only necessary if the recipe name does not >>> begin >>> -# with kernel-module-. >>> -# >>> -PKG_${PN} = "kernel-module-${PN}" >> > > > ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2013-08-16 15:23 UTC | newest] Thread overview: 5+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2013-08-14 16:41 Revert kernel-moudle- workaround for out-of-tree module package Yang Shi 2013-08-14 16:41 ` [PATCH] Revert "hello-mod: Ensure the produced package name begins with kernel-module-" Yang Shi 2013-08-14 18:10 ` Darren Hart 2013-08-14 18:35 ` Mark Hatle 2013-08-16 15:23 ` Yang Shi
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox