Patchwork [1/1] kernel: restore scripts in the sysroot

login
register
mail settings
Submitter Bruce Ashfield
Date Oct. 8, 2013, 9:12 p.m.
Message ID <9f62e2e632692c5919a0de25a785d17d477a64b3.1381266484.git.bruce.ashfield@windriver.com>
Download mbox | patch
Permalink /patch/59519/
State Accepted
Commit 5bcd65807aa634060f98928db6011856934dabe4
Headers show

Comments

Bruce Ashfield - Oct. 8, 2013, 9:12 p.m.
When building against the sysroot, out of tree modules can require modpost
and other utilities normally found in the kernel's scripts directory. For
the kernel source in the staging dir, these scripts have been removed to
avoid mixing archiectures when packaging kernel-dev (among other things).

Rather than further complicate the kernel's install rule, or its packaging,
we can restore the scripts by building them in the kernel staging directory
after the sstate is installed, making them available to packages that need them.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel.bbclass | 11 +++++++++++
 1 file changed, 11 insertions(+)
Mike Crowe - Nov. 19, 2013, 5:37 p.m.
On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
> When building against the sysroot, out of tree modules can require modpost
> and other utilities normally found in the kernel's scripts directory. For
> the kernel source in the staging dir, these scripts have been removed to
> avoid mixing archiectures when packaging kernel-dev (among other things).
> 
> Rather than further complicate the kernel's install rule, or its packaging,
> we can restore the scripts by building them in the kernel staging directory
> after the sstate is installed, making them available to packages that need them.
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/classes/kernel.bbclass | 11 +++++++++++
>  1 file changed, 11 insertions(+)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 4acfb7e..d5fa801 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -292,6 +292,17 @@ kernel_do_install() {
>  }
>  do_install[prefuncs] += "package_get_auto_pr"
>  
> +
> +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
> +kernelscripts_sstate_postinst () {
> +	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
> +		( 
> +		  cd ${STAGING_KERNEL_DIR}
> +		  oe_runmake scripts
> +		)
> +	fi
> +}
> +
>  sysroot_stage_all_append() {
>  	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>  }

This sstate_postinst fails for me when the compiler isn't already present
in the sysroot.

Also, I notice that the environment and parameters passed to oe_runmake are
not the same as those used by kernel_do_compile etc.

Patches to follow.

Mike.
Phil Blundell - Nov. 19, 2013, 5:46 p.m.
On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote:
> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
> > When building against the sysroot, out of tree modules can require modpost
> > and other utilities normally found in the kernel's scripts directory. For
> > the kernel source in the staging dir, these scripts have been removed to
> > avoid mixing archiectures when packaging kernel-dev (among other things).
> > 
> > Rather than further complicate the kernel's install rule, or its packaging,
> > we can restore the scripts by building them in the kernel staging directory
> > after the sstate is installed, making them available to packages that need them.
> > 
> > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> > ---
> >  meta/classes/kernel.bbclass | 11 +++++++++++
> >  1 file changed, 11 insertions(+)
> > 
> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> > index 4acfb7e..d5fa801 100644
> > --- a/meta/classes/kernel.bbclass
> > +++ b/meta/classes/kernel.bbclass
> > @@ -292,6 +292,17 @@ kernel_do_install() {
> >  }
> >  do_install[prefuncs] += "package_get_auto_pr"
> >  
> > +
> > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
> > +kernelscripts_sstate_postinst () {
> > +	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
> > +		( 
> > +		  cd ${STAGING_KERNEL_DIR}
> > +		  oe_runmake scripts
> > +		)
> > +	fi
> > +}
> > +
> >  sysroot_stage_all_append() {
> >  	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
> >  }
> 
> This sstate_postinst fails for me when the compiler isn't already present
> in the sysroot.
> 
> Also, I notice that the environment and parameters passed to oe_runmake are
> not the same as those used by kernel_do_compile etc.

Also note that module.bbclass already does "make scripts" before
do_compile() so out-of-tree modules should already have access to all
the files that they need.  

If we're going to make a policy decision that the kernel is responsible
for making scripts then I guess that's fine (modulo the implementation
problems that Mike describes) but in that case the code in
module{-base}.bbclass is redundant and ought to be removed.

p.
Bruce Ashfield - Nov. 19, 2013, 5:54 p.m.
On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote:
>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
>> > When building against the sysroot, out of tree modules can require modpost
>> > and other utilities normally found in the kernel's scripts directory. For
>> > the kernel source in the staging dir, these scripts have been removed to
>> > avoid mixing archiectures when packaging kernel-dev (among other things).
>> >
>> > Rather than further complicate the kernel's install rule, or its packaging,
>> > we can restore the scripts by building them in the kernel staging directory
>> > after the sstate is installed, making them available to packages that need them.
>> >
>> > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> > ---
>> >  meta/classes/kernel.bbclass | 11 +++++++++++
>> >  1 file changed, 11 insertions(+)
>> >
>> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> > index 4acfb7e..d5fa801 100644
>> > --- a/meta/classes/kernel.bbclass
>> > +++ b/meta/classes/kernel.bbclass
>> > @@ -292,6 +292,17 @@ kernel_do_install() {
>> >  }
>> >  do_install[prefuncs] += "package_get_auto_pr"
>> >
>> > +
>> > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
>> > +kernelscripts_sstate_postinst () {
>> > +   if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>> > +           (
>> > +             cd ${STAGING_KERNEL_DIR}
>> > +             oe_runmake scripts
>> > +           )
>> > +   fi
>> > +}
>> > +
>> >  sysroot_stage_all_append() {
>> >     sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>> >  }
>>
>> This sstate_postinst fails for me when the compiler isn't already present
>> in the sysroot.
>>
>> Also, I notice that the environment and parameters passed to oe_runmake are
>> not the same as those used by kernel_do_compile etc.
>
> Also note that module.bbclass already does "make scripts" before
> do_compile() so out-of-tree modules should already have access to all
> the files that they need.

Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
Khem was building out of the sysroot and the support scripts weren't present,
something which we were able to consistently reproduce.

Perhaps the whole problem was just a misordering of the tasks. I'll take another
look.

But yes, we need one way or the other .. not both. I'd prefer to not fiddle with
sstate, so I'll go back and see why the module.bbclass code wasn't working
for the reported error.

Bruce


>
> If we're going to make a policy decision that the kernel is responsible
> for making scripts then I guess that's fine (modulo the implementation
> problems that Mike describes) but in that case the code in
> module{-base}.bbclass is redundant and ought to be removed.
>
> p.
>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
Bruce Ashfield - Nov. 19, 2013, 6:17 p.m.
Adding Khem.

Khem .. see below.

On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield
<bruce.ashfield@gmail.com> wrote:
> On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote:
>> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote:
>>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
>>> > When building against the sysroot, out of tree modules can require modpost
>>> > and other utilities normally found in the kernel's scripts directory. For
>>> > the kernel source in the staging dir, these scripts have been removed to
>>> > avoid mixing archiectures when packaging kernel-dev (among other things).
>>> >
>>> > Rather than further complicate the kernel's install rule, or its packaging,
>>> > we can restore the scripts by building them in the kernel staging directory
>>> > after the sstate is installed, making them available to packages that need them.
>>> >
>>> > Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>> > ---
>>> >  meta/classes/kernel.bbclass | 11 +++++++++++
>>> >  1 file changed, 11 insertions(+)
>>> >
>>> > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>> > index 4acfb7e..d5fa801 100644
>>> > --- a/meta/classes/kernel.bbclass
>>> > +++ b/meta/classes/kernel.bbclass
>>> > @@ -292,6 +292,17 @@ kernel_do_install() {
>>> >  }
>>> >  do_install[prefuncs] += "package_get_auto_pr"
>>> >
>>> > +
>>> > +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
>>> > +kernelscripts_sstate_postinst () {
>>> > +   if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>>> > +           (
>>> > +             cd ${STAGING_KERNEL_DIR}
>>> > +             oe_runmake scripts
>>> > +           )
>>> > +   fi
>>> > +}
>>> > +
>>> >  sysroot_stage_all_append() {
>>> >     sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>>> >  }
>>>
>>> This sstate_postinst fails for me when the compiler isn't already present
>>> in the sysroot.
>>>
>>> Also, I notice that the environment and parameters passed to oe_runmake are
>>> not the same as those used by kernel_do_compile etc.
>>
>> Also note that module.bbclass already does "make scripts" before
>> do_compile() so out-of-tree modules should already have access to all
>> the files that they need.
>
> Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
> Khem was building out of the sysroot and the support scripts weren't present,
> something which we were able to consistently reproduce.
>
> Perhaps the whole problem was just a misordering of the tasks. I'll take another
> look.
>
> But yes, we need one way or the other .. not both. I'd prefer to not fiddle with
> sstate, so I'll go back and see why the module.bbclass code wasn't working
> for the reported error.

Khem: I wasn't working from a bugzilla when making these changes, so I
can't find your original reproducer for the missing recordmcount script.

Do you recall what it was ? I'm revisiting this and would like to understand
why the make scripts in module-base.bbclass wasn't properly restoring
the support scripts for your build.

I'm leaning towards reverting the whole mess, but without the reproducing
case, I can't be sure that I'm not breaking you again.

Bruce

>
> Bruce
>
>
>>
>> If we're going to make a policy decision that the kernel is responsible
>> for making scripts then I guess that's fine (modulo the implementation
>> problems that Mike describes) but in that case the code in
>> module{-base}.bbclass is redundant and ought to be removed.
>>
>> p.
>>
>>
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
Khem Raj - Nov. 19, 2013, 10:29 p.m.
On Nov 19, 2013, at 10:17 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:

> Adding Khem.
> 
> Khem .. see below.
> 
> On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield
> <bruce.ashfield@gmail.com> wrote:
>> On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote:
>>> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote:
>>>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
>>>>> When building against the sysroot, out of tree modules can require modpost
>>>>> and other utilities normally found in the kernel's scripts directory. For
>>>>> the kernel source in the staging dir, these scripts have been removed to
>>>>> avoid mixing archiectures when packaging kernel-dev (among other things).
>>>>> 
>>>>> Rather than further complicate the kernel's install rule, or its packaging,
>>>>> we can restore the scripts by building them in the kernel staging directory
>>>>> after the sstate is installed, making them available to packages that need them.
>>>>> 
>>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>>> ---
>>>>> meta/classes/kernel.bbclass | 11 +++++++++++
>>>>> 1 file changed, 11 insertions(+)
>>>>> 
>>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>>> index 4acfb7e..d5fa801 100644
>>>>> --- a/meta/classes/kernel.bbclass
>>>>> +++ b/meta/classes/kernel.bbclass
>>>>> @@ -292,6 +292,17 @@ kernel_do_install() {
>>>>> }
>>>>> do_install[prefuncs] += "package_get_auto_pr"
>>>>> 
>>>>> +
>>>>> +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
>>>>> +kernelscripts_sstate_postinst () {
>>>>> +   if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>>>>> +           (
>>>>> +             cd ${STAGING_KERNEL_DIR}
>>>>> +             oe_runmake scripts
>>>>> +           )
>>>>> +   fi
>>>>> +}
>>>>> +
>>>>> sysroot_stage_all_append() {
>>>>>    sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>>>>> }
>>>> 
>>>> This sstate_postinst fails for me when the compiler isn't already present
>>>> in the sysroot.
>>>> 
>>>> Also, I notice that the environment and parameters passed to oe_runmake are
>>>> not the same as those used by kernel_do_compile etc.
>>> 
>>> Also note that module.bbclass already does "make scripts" before
>>> do_compile() so out-of-tree modules should already have access to all
>>> the files that they need.
>> 
>> Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
>> Khem was building out of the sysroot and the support scripts weren't present,
>> something which we were able to consistently reproduce.
>> 
>> Perhaps the whole problem was just a misordering of the tasks. I'll take another
>> look.
>> 
>> But yes, we need one way or the other .. not both. I'd prefer to not fiddle with
>> sstate, so I'll go back and see why the module.bbclass code wasn't working
>> for the reported error.
> 
> Khem: I wasn't working from a bugzilla when making these changes, so I
> can't find your original reproducer for the missing recordmcount script.
> 
> Do you recall what it was ? I'm revisiting this and would like to understand
> why the make scripts in module-base.bbclass wasn't properly restoring
> the support scripts for your build.
> 
> I'm leaning towards reverting the whole mess, but without the reproducing
> case, I can't be sure that I'm not breaking you again.

Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
if external module also comes from sstate then it all is fine. Its only when everything is coming from
sstate except this external module which needs to be rebuilt then you see this problem.

now, I see the code in module-base.class

#
# Ensure the hostprogs are available for module compilation. Modules that
# inherit this recipe and override do_compile() should be sure to call
# do_make_scripts() or ensure the scripts are built independently.
#
do_make_scripts() {
        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
        make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
                   -C ${STAGING_KERNEL_DIR} scripts
}

so it expects that, do_make_scripts is explicitly called by external module recipes

and my recipes did override module_do_compile task but not do_compile like below

module_do_compile() {
        oe_runmake
}

so, is comment wrong there should it say module_do_compile instead ?

will it work with sstate always ?

it will be OK to revert it if thats the case.

> 
> Bruce
> 
>> 
>> Bruce
>> 
>> 
>>> 
>>> If we're going to make a policy decision that the kernel is responsible
>>> for making scripts then I guess that's fine (modulo the implementation
>>> problems that Mike describes) but in that case the code in
>>> module{-base}.bbclass is redundant and ought to be removed.
>>> 
>>> p.
>>> 
>>> 
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core@lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>> 
>> 
>> 
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
> 
> 
> 
> -- 
> "Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end"
Richard Purdie - Nov. 19, 2013, 10:36 p.m.
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:

> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
> if external module also comes from sstate then it all is fine. Its only when everything is coming from
> sstate except this external module which needs to be rebuilt then you see this problem.
> 
> now, I see the code in module-base.class
> 
> #
> # Ensure the hostprogs are available for module compilation. Modules that
> # inherit this recipe and override do_compile() should be sure to call
> # do_make_scripts() or ensure the scripts are built independently.
> #
> do_make_scripts() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
>         make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>                    -C ${STAGING_KERNEL_DIR} scripts
> }
> 
> so it expects that, do_make_scripts is explicitly called by external module recipes
> 
> and my recipes did override module_do_compile task but not do_compile like below
> 
> module_do_compile() {
>         oe_runmake
> }
> 
> so, is comment wrong there should it say module_do_compile instead ?
> 
> will it work with sstate always ?
> 
> it will be OK to revert it if thats the case.

Did you inherit module-base or module? I think the wording applies to
module and not module-base. I think the function used to be in module
and was moved along with the comment which is now incorrect.

Cheers,

Richard
Bruce Ashfield - Nov. 19, 2013, 10:37 p.m.
On Tue, Nov 19, 2013 at 5:29 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
> On Nov 19, 2013, at 10:17 AM, Bruce Ashfield <bruce.ashfield@gmail.com> wrote:
>
>> Adding Khem.
>>
>> Khem .. see below.
>>
>> On Tue, Nov 19, 2013 at 12:54 PM, Bruce Ashfield
>> <bruce.ashfield@gmail.com> wrote:
>>> On Tue, Nov 19, 2013 at 12:46 PM, Phil Blundell <pb@pbcl.net> wrote:
>>>> On Tue, 2013-11-19 at 17:37 +0000, Mike Crowe wrote:
>>>>> On Tuesday 08 October 2013 at 17:12:54 -0400, Bruce Ashfield wrote:
>>>>>> When building against the sysroot, out of tree modules can require modpost
>>>>>> and other utilities normally found in the kernel's scripts directory. For
>>>>>> the kernel source in the staging dir, these scripts have been removed to
>>>>>> avoid mixing archiectures when packaging kernel-dev (among other things).
>>>>>>
>>>>>> Rather than further complicate the kernel's install rule, or its packaging,
>>>>>> we can restore the scripts by building them in the kernel staging directory
>>>>>> after the sstate is installed, making them available to packages that need them.
>>>>>>
>>>>>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>>>>>> ---
>>>>>> meta/classes/kernel.bbclass | 11 +++++++++++
>>>>>> 1 file changed, 11 insertions(+)
>>>>>>
>>>>>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>>>>>> index 4acfb7e..d5fa801 100644
>>>>>> --- a/meta/classes/kernel.bbclass
>>>>>> +++ b/meta/classes/kernel.bbclass
>>>>>> @@ -292,6 +292,17 @@ kernel_do_install() {
>>>>>> }
>>>>>> do_install[prefuncs] += "package_get_auto_pr"
>>>>>>
>>>>>> +
>>>>>> +SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
>>>>>> +kernelscripts_sstate_postinst () {
>>>>>> +   if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>>>>>> +           (
>>>>>> +             cd ${STAGING_KERNEL_DIR}
>>>>>> +             oe_runmake scripts
>>>>>> +           )
>>>>>> +   fi
>>>>>> +}
>>>>>> +
>>>>>> sysroot_stage_all_append() {
>>>>>>    sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>>>>>> }
>>>>>
>>>>> This sstate_postinst fails for me when the compiler isn't already present
>>>>> in the sysroot.
>>>>>
>>>>> Also, I notice that the environment and parameters passed to oe_runmake are
>>>>> not the same as those used by kernel_do_compile etc.
>>>>
>>>> Also note that module.bbclass already does "make scripts" before
>>>> do_compile() so out-of-tree modules should already have access to all
>>>> the files that they need.
>>>
>>> Ah, but they didn't. Otherwise we wouldn't have mucked about in the routines.
>>> Khem was building out of the sysroot and the support scripts weren't present,
>>> something which we were able to consistently reproduce.
>>>
>>> Perhaps the whole problem was just a misordering of the tasks. I'll take another
>>> look.
>>>
>>> But yes, we need one way or the other .. not both. I'd prefer to not fiddle with
>>> sstate, so I'll go back and see why the module.bbclass code wasn't working
>>> for the reported error.
>>
>> Khem: I wasn't working from a bugzilla when making these changes, so I
>> can't find your original reproducer for the missing recordmcount script.
>>
>> Do you recall what it was ? I'm revisiting this and would like to understand
>> why the make scripts in module-base.bbclass wasn't properly restoring
>> the support scripts for your build.
>>
>> I'm leaning towards reverting the whole mess, but without the reproducing
>> case, I can't be sure that I'm not breaking you again.
>
> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
> if external module also comes from sstate then it all is fine. Its only when everything is coming from
> sstate except this external module which needs to be rebuilt then you see this problem.
>

Right.

> now, I see the code in module-base.class
>
> #
> # Ensure the hostprogs are available for module compilation. Modules that
> # inherit this recipe and override do_compile() should be sure to call
> # do_make_scripts() or ensure the scripts are built independently.
> #
> do_make_scripts() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>         make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>                    -C ${STAGING_KERNEL_DIR} scripts
> }
>
> so it expects that, do_make_scripts is explicitly called by external module recipes
>

Exactly. And I had windriver bug with the same symptoms as yours. It
was a package
that built its own modules, and hence never called this either.

> and my recipes did override module_do_compile task but not do_compile like below
>
> module_do_compile() {
>         oe_runmake
> }
>
> so, is comment wrong there should it say module_do_compile instead ?
>
> will it work with sstate always ?
>
> it will be OK to revert it if thats the case.

I'll come up with something that works in all cases. The sstate fix is
better from the point
of view that it is transparent to the recipes, and they don't need to
do anything special
for the support.

So my proposal is this:

 - fix the new bug at hand by making the sstate change depend on the
toolchain (I agree
   that patching the scripts to not reference the target toolchain
isn't a good idea since not
  all kernels get the rix).

 - remove the modules-base.bbclass scripts recreation, so we only have
one scripts
   restore in the tree.

Alternatively, recipes need to be fixed to call the
modules-base.bbclass routine to restore
scripts, and I think it is obvious that won't work in all cases.

I'll wait for comments/concensus before sending a new patch (which
needs to be tested
on all the cases), but in the meantime, the patches to the list to fix
the sstate solution
are good to be applied.

Cheers,

Bruce

>
>>
>> Bruce
>>
>>>
>>> Bruce
>>>
>>>
>>>>
>>>> If we're going to make a policy decision that the kernel is responsible
>>>> for making scripts then I guess that's fine (modulo the implementation
>>>> problems that Mike describes) but in that case the code in
>>>> module{-base}.bbclass is redundant and ought to be removed.
>>>>
>>>> p.
>>>>
>>>>
>>>> _______________________________________________
>>>> Openembedded-core mailing list
>>>> Openembedded-core@lists.openembedded.org
>>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>
Khem Raj - Nov. 19, 2013, 10:39 p.m.
On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
> 
>> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
>> if external module also comes from sstate then it all is fine. Its only when everything is coming from
>> sstate except this external module which needs to be rebuilt then you see this problem.
>> 
>> now, I see the code in module-base.class
>> 
>> #
>> # Ensure the hostprogs are available for module compilation. Modules that
>> # inherit this recipe and override do_compile() should be sure to call
>> # do_make_scripts() or ensure the scripts are built independently.
>> #
>> do_make_scripts() {
>>        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
>>        make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>>                   -C ${STAGING_KERNEL_DIR} scripts
>> }
>> 
>> so it expects that, do_make_scripts is explicitly called by external module recipes
>> 
>> and my recipes did override module_do_compile task but not do_compile like below
>> 
>> module_do_compile() {
>>        oe_runmake
>> }
>> 
>> so, is comment wrong there should it say module_do_compile instead ?
>> 
>> will it work with sstate always ?
>> 
>> it will be OK to revert it if thats the case.
> 
> Did you inherit module-base or module? I think the wording applies to
> module and not module-base. I think the function used to be in module
> and was moved along with the comment which is now incorrect.
> 

inherit module 


> Cheers,
> 
> Richard
> 
>
Richard Purdie - Nov. 19, 2013, 10:42 p.m.
On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
> 
> Exactly. And I had windriver bug with the same symptoms as yours. It
> was a package
> that built its own modules, and hence never called this either.
> 
> > and my recipes did override module_do_compile task but not do_compile like below
> >
> > module_do_compile() {
> >         oe_runmake
> > }
> >
> > so, is comment wrong there should it say module_do_compile instead ?
> >
> > will it work with sstate always ?
> >
> > it will be OK to revert it if thats the case.
> 
> I'll come up with something that works in all cases. The sstate fix is
> better from the point
> of view that it is transparent to the recipes, and they don't need to
> do anything special
> for the support.
> 
> So my proposal is this:
> 
>  - fix the new bug at hand by making the sstate change depend on the
> toolchain (I agree
>    that patching the scripts to not reference the target toolchain
> isn't a good idea since not
>   all kernels get the rix).

Can we please not do this? Adding in toolchain dependencies into the
sstate code whilst possible, is going to massively complicate the
dependency chains and is a last possible resort. I bought that argument
in the useradd case since there are horrible issues there. We don't have
that issue here.

In kernel terms, its safer/easier to hack the kernel makefiles than
expecting sstate to work well with dependencies like that embedded in
it.

>  - remove the modules-base.bbclass scripts recreation, so we only have
> one scripts
>    restore in the tree.
> 
> Alternatively, recipes need to be fixed to call the
> modules-base.bbclass routine to restore
> scripts, and I think it is obvious that won't work in all cases.

Which cases won't that work in?

As far as I'm concerned, people using module-base are taking a loaded
gun and are expected to use it safely (which means calling
do_make_scripts somehow). People wanting a safer ride can use module
which adds the appropriate task for them.

The comments in the bbclass files do need fixing but that is trivial to
sort out.

> I'll wait for comments/concensus before sending a new patch (which
> needs to be tested
> on all the cases), but in the meantime, the patches to the list to fix
> the sstate solution are good to be applied.

I will respectfully disagree ;-).

Cheers,

Richard
Richard Purdie - Nov. 19, 2013, 10:45 p.m.
On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> 
> > On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
> > 
> >> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
> >> if external module also comes from sstate then it all is fine. Its only when everything is coming from
> >> sstate except this external module which needs to be rebuilt then you see this problem.
> >> 
> >> now, I see the code in module-base.class
> >> 
> >> #
> >> # Ensure the hostprogs are available for module compilation. Modules that
> >> # inherit this recipe and override do_compile() should be sure to call
> >> # do_make_scripts() or ensure the scripts are built independently.
> >> #
> >> do_make_scripts() {
> >>        unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
> >>        make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
> >>                   -C ${STAGING_KERNEL_DIR} scripts
> >> }
> >> 
> >> so it expects that, do_make_scripts is explicitly called by external module recipes
> >> 
> >> and my recipes did override module_do_compile task but not do_compile like below
> >> 
> >> module_do_compile() {
> >>        oe_runmake
> >> }
> >> 
> >> so, is comment wrong there should it say module_do_compile instead ?
> >> 
> >> will it work with sstate always ?
> >> 
> >> it will be OK to revert it if thats the case.
> > 
> > Did you inherit module-base or module? I think the wording applies to
> > module and not module-base. I think the function used to be in module
> > and was moved along with the comment which is now incorrect.
> > 
> 
> inherit module 

So in that case there is:

addtask make_scripts after do_patch before do_compile
do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
do_make_scripts[deptask] = "do_populate_sysroot"

which forces the make_scripts task to run before compile. I don't see
how that could therefore fail? :/

Do you have a copy of the exact log? I'm wondering if this is another
variant of the bitbake dependency bug I just tracked down
(http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)

Cheers,

Richard
Bruce Ashfield - Nov. 19, 2013, 10:46 p.m.
On Tue, Nov 19, 2013 at 5:42 PM, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
>>
>> Exactly. And I had windriver bug with the same symptoms as yours. It
>> was a package
>> that built its own modules, and hence never called this either.
>>
>> > and my recipes did override module_do_compile task but not do_compile like below
>> >
>> > module_do_compile() {
>> >         oe_runmake
>> > }
>> >
>> > so, is comment wrong there should it say module_do_compile instead ?
>> >
>> > will it work with sstate always ?
>> >
>> > it will be OK to revert it if thats the case.
>>
>> I'll come up with something that works in all cases. The sstate fix is
>> better from the point
>> of view that it is transparent to the recipes, and they don't need to
>> do anything special
>> for the support.
>>
>> So my proposal is this:
>>
>>  - fix the new bug at hand by making the sstate change depend on the
>> toolchain (I agree
>>    that patching the scripts to not reference the target toolchain
>> isn't a good idea since not
>>   all kernels get the rix).
>
> Can we please not do this? Adding in toolchain dependencies into the
> sstate code whilst possible, is going to massively complicate the
> dependency chains and is a last possible resort. I bought that argument
> in the useradd case since there are horrible issues there. We don't have
> that issue here.
>

Works for me. I just wonder if there's another way to handle things
more gracefully ? i.e. somehow check if the toolchain isn't available
and warn, otherwise continue making the scripts ?

> In kernel terms, its safer/easier to hack the kernel makefiles than
> expecting sstate to work well with dependencies like that embedded in
> it.

It is pretty simple to make the change. Just making it available everywhere
is the trick.

>
>>  - remove the modules-base.bbclass scripts recreation, so we only have
>> one scripts
>>    restore in the tree.
>>
>> Alternatively, recipes need to be fixed to call the
>> modules-base.bbclass routine to restore
>> scripts, and I think it is obvious that won't work in all cases.
>
> Which cases won't that work in?
>
> As far as I'm concerned, people using module-base are taking a loaded
> gun and are expected to use it safely (which means calling
> do_make_scripts somehow). People wanting a safer ride can use module
> which adds the appropriate task for them.

I've got people not using any of the above .. yes, I know they are evil
too :)

>
> The comments in the bbclass files do need fixing but that is trivial to
> sort out.
>
>> I'll wait for comments/concensus before sending a new patch (which
>> needs to be tested
>> on all the cases), but in the meantime, the patches to the list to fix
>> the sstate solution are good to be applied.
>
> I will respectfully disagree ;-).

No patch from me for this then. That's why i waited, I figured it wouldn't
be immediate agreement.

Bruce

>
> Cheers,
>
> Richard
>
Bruce Ashfield - Nov. 19, 2013, 10:48 p.m.
On Tue, Nov 19, 2013 at 6:44 PM, Phil Blundell <pb@pbcl.net> wrote:
> On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
>> Alternatively, recipes need to be fixed to call the
>> modules-base.bbclass routine to restore
>> scripts, and I think it is obvious that won't work in all cases.
>
> Admittedly I'm no expert, but this is not obvious to me.  Why can't
> those recipes just be fixed to do the right thing?

Alas, people with legacy build environments that they've wrapped and ported
to bitbake .. they either can't or won't change, so I'm stuck at least trying
to detect them.

That wasn't the primary driver for this though, if that case breaks, they'll
live and so will i :)

I think we are converging to removing the sstate scripts restore, which is
fine with me a this point, as long as Khem isn't broken.

Bruce

>
> p.
>
>
Phil Blundell - Nov. 19, 2013, 11:41 p.m.
On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
> if external module also comes from sstate then it all is fine. Its only when everything is coming from
> sstate except this external module which needs to be rebuilt then you see this problem.
> 
> now, I see the code in module-base.class
> 
> #
> # Ensure the hostprogs are available for module compilation. Modules that
> # inherit this recipe and override do_compile() should be sure to call
> # do_make_scripts() or ensure the scripts are built independently.
> #
> do_make_scripts() {
>         unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
>         make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>                    -C ${STAGING_KERNEL_DIR} scripts
> }
> 
> so it expects that, do_make_scripts is explicitly called by external module recipes
> 
> and my recipes did override module_do_compile task but not do_compile like below
> 
> module_do_compile() {
>         oe_runmake
> }
> 
> so, is comment wrong there should it say module_do_compile instead ?

The comment is slightly wrong, yes.  For correct results you need to
either:

1. inherit module (not module-base), which does:

addtask make_scripts after do_patch before do_compile

and will ensure that the scripts are built before your module is
compiled without you needing to do anything else.  Or...

2. inherit module-base and arrange to call do_make_scripts() explicitly
from your own recipe.

p.
Phil Blundell - Nov. 19, 2013, 11:44 p.m.
On Tue, 2013-11-19 at 17:37 -0500, Bruce Ashfield wrote:
> Alternatively, recipes need to be fixed to call the
> modules-base.bbclass routine to restore
> scripts, and I think it is obvious that won't work in all cases.

Admittedly I'm no expert, but this is not obvious to me.  Why can't
those recipes just be fixed to do the right thing?

p.
Khem Raj - Nov. 20, 2013, 2:59 a.m.
On Nov 19, 2013, at 2:45 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:

> On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
>> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>> 
>>> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
>>> 
>>>> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
>>>> if external module also comes from sstate then it all is fine. Its only when everything is coming from
>>>> sstate except this external module which needs to be rebuilt then you see this problem.
>>>> 
>>>> now, I see the code in module-base.class
>>>> 
>>>> #
>>>> # Ensure the hostprogs are available for module compilation. Modules that
>>>> # inherit this recipe and override do_compile() should be sure to call
>>>> # do_make_scripts() or ensure the scripts are built independently.
>>>> #
>>>> do_make_scripts() {
>>>>       unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS 
>>>>       make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>>>>                  -C ${STAGING_KERNEL_DIR} scripts
>>>> }
>>>> 
>>>> so it expects that, do_make_scripts is explicitly called by external module recipes
>>>> 
>>>> and my recipes did override module_do_compile task but not do_compile like below
>>>> 
>>>> module_do_compile() {
>>>>       oe_runmake
>>>> }
>>>> 
>>>> so, is comment wrong there should it say module_do_compile instead ?
>>>> 
>>>> will it work with sstate always ?
>>>> 
>>>> it will be OK to revert it if thats the case.
>>> 
>>> Did you inherit module-base or module? I think the wording applies to
>>> module and not module-base. I think the function used to be in module
>>> and was moved along with the comment which is now incorrect.
>>> 
>> 
>> inherit module 
> 
> So in that case there is:
> 
> addtask make_scripts after do_patch before do_compile
> do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
> do_make_scripts[deptask] = “do_populate_sysroot”
> 

yes I see.


> which forces the make_scripts task to run before compile. I don't see
> how that could therefore fail? :/
> 
> Do you have a copy of the exact log?

Not anymore, it was sometime ago, the logs are unfortunately recycled.

> I'm wondering if this is another
> variant of the bitbake dependency bug I just tracked down
> (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
> 

ah very likely, I think I will try this fix and revert the kernel.bbclass fix locally and see if I still am
able to reproduce this issue. In any case I think the kernel.bbclass may be abandoned since I now think it
was a wrong fix although it did fix the problem

> Cheers,
> 
> Richard
>
Bruce Ashfield - Nov. 20, 2013, 4:43 a.m.
On Tue, Nov 19, 2013 at 9:59 PM, Khem Raj <raj.khem@gmail.com> wrote:
>
> On Nov 19, 2013, at 2:45 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>
>> On Tue, 2013-11-19 at 14:39 -0800, Khem Raj wrote:
>>> On Nov 19, 2013, at 2:36 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>>
>>>> On Tue, 2013-11-19 at 14:29 -0800, Khem Raj wrote:
>>>>
>>>>> Well reproducer case is that build from sstate but such that an external module needs to be rebuilt
>>>>> if external module also comes from sstate then it all is fine. Its only when everything is coming from
>>>>> sstate except this external module which needs to be rebuilt then you see this problem.
>>>>>
>>>>> now, I see the code in module-base.class
>>>>>
>>>>> #
>>>>> # Ensure the hostprogs are available for module compilation. Modules that
>>>>> # inherit this recipe and override do_compile() should be sure to call
>>>>> # do_make_scripts() or ensure the scripts are built independently.
>>>>> #
>>>>> do_make_scripts() {
>>>>>       unset CFLAGS CPPFLAGS CXXFLAGS LDFLAGS
>>>>>       make CC="${KERNEL_CC}" LD="${KERNEL_LD}" AR="${KERNEL_AR}" \
>>>>>                  -C ${STAGING_KERNEL_DIR} scripts
>>>>> }
>>>>>
>>>>> so it expects that, do_make_scripts is explicitly called by external module recipes
>>>>>
>>>>> and my recipes did override module_do_compile task but not do_compile like below
>>>>>
>>>>> module_do_compile() {
>>>>>       oe_runmake
>>>>> }
>>>>>
>>>>> so, is comment wrong there should it say module_do_compile instead ?
>>>>>
>>>>> will it work with sstate always ?
>>>>>
>>>>> it will be OK to revert it if thats the case.
>>>>
>>>> Did you inherit module-base or module? I think the wording applies to
>>>> module and not module-base. I think the function used to be in module
>>>> and was moved along with the comment which is now incorrect.
>>>>
>>>
>>> inherit module
>>
>> So in that case there is:
>>
>> addtask make_scripts after do_patch before do_compile
>> do_make_scripts[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
>> do_make_scripts[deptask] = “do_populate_sysroot”
>>
>
> yes I see.
>
>
>> which forces the make_scripts task to run before compile. I don't see
>> how that could therefore fail? :/
>>
>> Do you have a copy of the exact log?
>
> Not anymore, it was sometime ago, the logs are unfortunately recycled.
>
>> I'm wondering if this is another
>> variant of the bitbake dependency bug I just tracked down
>> (http://git.yoctoproject.org/cgit.cgi/poky-contrib/patch/?id=7b49d336c4672f3dfa78e1c3f1f5c7384264a118)
>>
>
> ah very likely, I think I will try this fix and revert the kernel.bbclass fix locally and see if I still am
> able to reproduce this issue. In any case I think the kernel.bbclass may be abandoned since I now think it
> was a wrong fix although it did fix the problem
>

Agreed.

Since you have control over your recipes, you don't have to worry
about some of the more evil ones that build, and inside their own build head
reference the kernel-staging tree and attempt to build modules. Just getting
the right inheritance should fix it up.

The other case is a different concern, and even then, including module, and
overriding the do_compile() should work to get the scripts restored and not
just attempt to launch a build.

I'm going to be in Transit tomorrow, so won't be all that responsive, but
my vote is now to simply revert the sstate scripts changes once Khem confirms
that he is ok for his builds.

Cheers,

Bruce

>> Cheers,
>>
>> Richard
>>
>

Patch

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d5fa801 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -292,6 +292,17 @@  kernel_do_install() {
 }
 do_install[prefuncs] += "package_get_auto_pr"
 
+
+SSTATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
+kernelscripts_sstate_postinst () {
+	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
+		( 
+		  cd ${STAGING_KERNEL_DIR}
+		  oe_runmake scripts
+		)
+	fi
+}
+
 sysroot_stage_all_append() {
 	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
 }