[PATCH 0/1] kernel: provide scripts in the sysroot

[PATCH 0/1] kernel: provide scripts in the sysroot

[Bruce Ashfield]

Richard/Saul,

Khem noticed that he was seeing frequent "modpost missing" messages in his
logs for out of tree builds. This is due to the missing kernel scripts, which
we remove for packaging reasons.

Rather than jiggle the kernel install rule itself, experience shows that just
heading to the sysroot and re-creating the scripts is easy enough to do.

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

   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 jump into the sysroot and restore the scripts by building them, hence
   making them available to packages that need them.

Khem confirmed that the same fix worked for him.

cc: Khem Raj <raj.khem@gmail.com>

Cheers,

Bruce


The following changes since commit e7a20238dc73bb449f15feaf0dead51daf796184:

  maintainers: Add some maintainers (2013-10-03 10:22:30 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib zedd/kernel-oe
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel-oe

Bruce Ashfield (1):
  kernel: restore scripts in the sysroot

 meta/classes/kernel.bbclass | 8 ++++++++
 1 file changed, 8 insertions(+)

-- 
1.8.1.2

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

[Bruce Ashfield]

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 jump into the sysroot and restore the scripts by building them, hence
making them available to packages that need them.

Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
---
 meta/classes/kernel.bbclass | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 4acfb7e..d856e31 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -294,6 +294,14 @@ do_install[prefuncs] += "package_get_auto_pr"
 
 sysroot_stage_all_append() {
 	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
+
+	# Restore kernel scripts in the sysroot, since they had to be removed during
+	# packaging to avoid mismatched arch QA errors, but are required/useful when
+	# packages like out of tree kernel modules are built. Rather than playing QA
+	# games, it is easier to just do this work in the sysroot.
+	( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
+	  oe_runmake scripts 
+	)
 }
 
 kernel_do_configure() {
-- 
1.8.1.2

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Khem Raj]

On Oct 3, 2013, at 5:02 PM, Bruce Ashfield <bruce.ashfield@windriver.com> 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 jump into the sysroot and restore the scripts by building them, hence
> making them available to packages that need them.
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
> meta/classes/kernel.bbclass | 8 ++++++++
> 1 file changed, 8 insertions(+)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index 4acfb7e..d856e31 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -294,6 +294,14 @@ do_install[prefuncs] += "package_get_auto_pr"
> 
> sysroot_stage_all_append() {
> 	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
> +
> +	# Restore kernel scripts in the sysroot, since they had to be removed during
> +	# packaging to avoid mismatched arch QA errors, but are required/useful when
> +	# packages like out of tree kernel modules are built. Rather than playing QA
> +	# games, it is easier to just do this work in the sysroot.
> +	( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};

This was cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}/scripts in my patch but I will test out this one too.
but this is ok since 

ifeq ($(KBUILD_EXTMOD),)
# Additional helpers built in scripts/
# Carefully list dependencies so we do not try to build scripts twice
# in parallel
PHONY += scripts
scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
         asm-generic
        $(Q)$(MAKE) $(build)=$(@)


> +	  oe_runmake scripts 
> +	)
> }
> 
> kernel_do_configure() {
> -- 
> 1.8.1.2
> 

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Bruce Ashfield]

On 13-10-03 8:58 PM, Khem Raj wrote:
>
> On Oct 3, 2013, at 5:02 PM, Bruce Ashfield <bruce.ashfield@windriver.com> 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 jump into the sysroot and restore the scripts by building them, hence
>> making them available to packages that need them.
>>
>> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
>> ---
>> meta/classes/kernel.bbclass | 8 ++++++++
>> 1 file changed, 8 insertions(+)
>>
>> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
>> index 4acfb7e..d856e31 100644
>> --- a/meta/classes/kernel.bbclass
>> +++ b/meta/classes/kernel.bbclass
>> @@ -294,6 +294,14 @@ do_install[prefuncs] += "package_get_auto_pr"
>>
>> sysroot_stage_all_append() {
>> 	sysroot_stage_dir ${D}${KERNEL_SRC_PATH} ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>> +
>> +	# Restore kernel scripts in the sysroot, since they had to be removed during
>> +	# packaging to avoid mismatched arch QA errors, but are required/useful when
>> +	# packages like out of tree kernel modules are built. Rather than playing QA
>> +	# games, it is easier to just do this work in the sysroot.
>> +	( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
>
> This was cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}/scripts in my patch but I will test out this one too.
> but this is ok since

Thanks. I went with habit and did it right from the top level. I see
modpost in my sysroot, but I definitely want to get your confirmation
that it works for you as well.

Bruce

>
> ifeq ($(KBUILD_EXTMOD),)
> # Additional helpers built in scripts/
> # Carefully list dependencies so we do not try to build scripts twice
> # in parallel
> PHONY += scripts
> scripts: scripts_basic include/config/auto.conf include/config/tristate.conf \
>           asm-generic
>          $(Q)$(MAKE) $(build)=$(@)
>
>
>> +	  oe_runmake scripts
>> +	)
>> }
>>
>> kernel_do_configure() {
>> --
>> 1.8.1.2
>>
>

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Richard Purdie]

On Thu, 2013-10-03 at 20:02 -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).

Its also to avoid mixing architectures when packaging the sstate for
do_populate_sysroot. The sstate for that task is now native arch
specific after this patch but its task hash is not. Even if we made it
native specific, that means the kernel would rebuild entirely if you
switch 32 bit to 64 bit native machine. We therefore cannot merge this
patch as is.

Instead do something like:


SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"

kernelheaders_sstate_postinst () {
	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
	then
		( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
		  oe_runmake scripts 
		)
	fi
}

This will rerun the oe_runmake scripts each time the sstate package is
installed. It slows down the use of sstate but should be correct whether
the build machine is 32 or 64 bit.


Cheers,

Richard

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Bruce Ashfield]

On 13-10-04 03:46 AM, Richard Purdie wrote:
> On Thu, 2013-10-03 at 20:02 -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).
>
> Its also to avoid mixing architectures when packaging the sstate for
> do_populate_sysroot. The sstate for that task is now native arch
> specific after this patch but its task hash is not. Even if we made it
> native specific, that means the kernel would rebuild entirely if you
> switch 32 bit to 64 bit native machine. We therefore cannot merge this
> patch as is.

Aha! I knew there was a lurking element I wouldn't know about. I nearly
put "RFC" in the patch .. and clearly should have :)

>
> Instead do something like:
>
>
> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"
>
> kernelheaders_sstate_postinst () {
> 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
> 	then
> 		( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
> 		  oe_runmake scripts
> 		)
> 	fi
> }
>
> This will rerun the oe_runmake scripts each time the sstate package is
> installed. It slows down the use of sstate but should be correct whether
> the build machine is 32 or 64 bit.

I'll try what you have above and re-spin the patch.

Cheers,

Bruce

>
>
> Cheers,
>
> Richard
>
>

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Khem Raj]

Bruce

Besides the sstate problem RP mentioned your patch worked fine.

On Fri, Oct 4, 2013 at 5:42 AM, Bruce Ashfield
<bruce.ashfield@windriver.com> wrote:
> On 13-10-04 03:46 AM, Richard Purdie wrote:
>>
>> On Thu, 2013-10-03 at 20:02 -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).
>>
>>
>> Its also to avoid mixing architectures when packaging the sstate for
>> do_populate_sysroot. The sstate for that task is now native arch
>> specific after this patch but its task hash is not. Even if we made it
>> native specific, that means the kernel would rebuild entirely if you
>> switch 32 bit to 64 bit native machine. We therefore cannot merge this
>> patch as is.
>
>
> Aha! I knew there was a lurking element I wouldn't know about. I nearly
> put "RFC" in the patch .. and clearly should have :)
>
>
>>
>> Instead do something like:
>>
>>
>> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"
>>
>> kernelheaders_sstate_postinst () {
>>         if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o
>> "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
>>         then
>>                 ( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
>>                   oe_runmake scripts
>>                 )
>>         fi
>> }
>>
>> This will rerun the oe_runmake scripts each time the sstate package is
>> installed. It slows down the use of sstate but should be correct whether
>> the build machine is 32 or 64 bit.
>
>
> I'll try what you have above and re-spin the patch.
>
> Cheers,
>
> Bruce
>
>>
>>
>> Cheers,
>>
>> Richard
>>
>>
>

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Bruce Ashfield]

On 13-10-04 3:46 AM, Richard Purdie wrote:
> On Thu, 2013-10-03 at 20:02 -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).
>
> Its also to avoid mixing architectures when packaging the sstate for
> do_populate_sysroot. The sstate for that task is now native arch
> specific after this patch but its task hash is not. Even if we made it
> native specific, that means the kernel would rebuild entirely if you
> switch 32 bit to 64 bit native machine. We therefore cannot merge this
> patch as is.
>
> Instead do something like:
>
>
> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"
>
> kernelheaders_sstate_postinst () {
> 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
> 	then
> 		( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
> 		  oe_runmake scripts
> 		)
> 	fi
> }
>
> This will rerun the oe_runmake scripts each time the sstate package is
> installed. It slows down the use of sstate but should be correct whether
> the build machine is 32 or 64 bit.

I poked with this a bit over the weekend, and never did get the right 
results.

I can make the scripts trigger, but since the sysroot population appears
to already be done, but build scripts don't actually make it into the
sysroot for use during module builds.

I tried a few variants of the below, all trying to get the actual
tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the
available variables didn't get me anything really promising either.

I'll have another look in the morning, since I'm sure it is just me not
understanding the ordering of things .. but any pointers would of course
be appreciated.

Cheers,

Bruce

STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
kernelscripts_sstate_postinst () {
         if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o 
"${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
                 sysroot_stage_dir ${D}${KERNEL_SRC_PATH} 
${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
                 oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts
	fi
} 
 



>
>
> Cheers,
>
> Richard
>
>

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Richard Purdie]

On Mon, 2013-10-07 at 01:02 -0400, Bruce Ashfield wrote:
> On 13-10-04 3:46 AM, Richard Purdie wrote:
> > On Thu, 2013-10-03 at 20:02 -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).
> >
> > Its also to avoid mixing architectures when packaging the sstate for
> > do_populate_sysroot. The sstate for that task is now native arch
> > specific after this patch but its task hash is not. Even if we made it
> > native specific, that means the kernel would rebuild entirely if you
> > switch 32 bit to 64 bit native machine. We therefore cannot merge this
> > patch as is.
> >
> > Instead do something like:
> >
> >
> > SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"
> >
> > kernelheaders_sstate_postinst () {
> > 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
> > 	then
> > 		( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
> > 		  oe_runmake scripts
> > 		)
> > 	fi
> > }
> >
> > This will rerun the oe_runmake scripts each time the sstate package is
> > installed. It slows down the use of sstate but should be correct whether
> > the build machine is 32 or 64 bit.
> 
> I poked with this a bit over the weekend, and never did get the right 
> results.
> 
> I can make the scripts trigger, but since the sysroot population appears
> to already be done, but build scripts don't actually make it into the
> sysroot for use during module builds.
> 
> I tried a few variants of the below, all trying to get the actual
> tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the
> available variables didn't get me anything really promising either.
> 
> I'll have another look in the morning, since I'm sure it is just me not
> understanding the ordering of things .. but any pointers would of course
> be appreciated.
> 
> Cheers,
> 
> Bruce
> 
> STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
> kernelscripts_sstate_postinst () {
>          if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o 
> "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>                  sysroot_stage_dir ${D}${KERNEL_SRC_PATH} 
> ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>                  oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts
> 	fi
> } 
>  

Ah, I had it slightly wrong. Try:

kernelheaders_sstate_postinst () {
 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
 	then
 		( cd ${KERNEL_SRC_PATH};
 		  oe_runmake scripts
 		)
 	fi
 }

since the files are actually installed at this point, therefore we
operate on the final location.

The risk here is that when we uninstall the sstate package, we don't
track the generated files. We can probably live with that for now.

What we really needs is a preinst but the one we have is really a
preunpack :/.

Ultimately, I think we need to rename the preinst to preunpack and add a
real preinst...

Cheers,

Richard

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Bruce Ashfield]

On 13-10-07 05:58 AM, Richard Purdie wrote:
> On Mon, 2013-10-07 at 01:02 -0400, Bruce Ashfield wrote:
>> On 13-10-04 3:46 AM, Richard Purdie wrote:
>>> On Thu, 2013-10-03 at 20:02 -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).
>>>
>>> Its also to avoid mixing architectures when packaging the sstate for
>>> do_populate_sysroot. The sstate for that task is now native arch
>>> specific after this patch but its task hash is not. Even if we made it
>>> native specific, that means the kernel would rebuild entirely if you
>>> switch 32 bit to 64 bit native machine. We therefore cannot merge this
>>> patch as is.
>>>
>>> Instead do something like:
>>>
>>>
>>> SSTATEPOSTINSTFUNCS += "kernelheaders_sstate_postinst"
>>>
>>> kernelheaders_sstate_postinst () {
>>> 	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
>>> 	then
>>> 		( cd ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH};
>>> 		  oe_runmake scripts
>>> 		)
>>> 	fi
>>> }
>>>
>>> This will rerun the oe_runmake scripts each time the sstate package is
>>> installed. It slows down the use of sstate but should be correct whether
>>> the build machine is 32 or 64 bit.
>>
>> I poked with this a bit over the weekend, and never did get the right
>> results.
>>
>> I can make the scripts trigger, but since the sysroot population appears
>> to already be done, but build scripts don't actually make it into the
>> sysroot for use during module builds.
>>
>> I tried a few variants of the below, all trying to get the actual
>> tmp/sysroots/<machine> to have the scripts, with no luck. Dumping the
>> available variables didn't get me anything really promising either.
>>
>> I'll have another look in the morning, since I'm sure it is just me not
>> understanding the ordering of things .. but any pointers would of course
>> be appreciated.
>>
>> Cheers,
>>
>> Bruce
>>
>> STATEPOSTINSTFUNCS += "kernelscripts_sstate_postinst"
>> kernelscripts_sstate_postinst () {
>>           if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o
>> "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]; then
>>                   sysroot_stage_dir ${D}${KERNEL_SRC_PATH}
>> ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH}
>>                   oe_runmake -C ${SYSROOT_DESTDIR}${KERNEL_SRC_PATH} scripts
>> 	fi
>> }
>>
>
> Ah, I had it slightly wrong. Try:
>
> kernelheaders_sstate_postinst () {
>   	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
>   	then
>   		( cd ${KERNEL_SRC_PATH};
>   		  oe_runmake scripts
>   		)
>   	fi
>   }
>
> since the files are actually installed at this point, therefore we
> operate on the final location.

That's the kicker, I can't get the right variable to find the final
location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate
on it directly. When things were runing in the sysroot_append, the
kernel src was staged, and then operated on, then it makes it into the
sysroot. Here, we could operate on the STAGING_KERNEL, which is in the
sysroot, but stripped of the scripts. Perhaps that is the answer, but
I need to confirm that scripts installed in that location would be
available to the out of tree module builds that are looking for modpost
and friends.

>
> The risk here is that when we uninstall the sstate package, we don't
> track the generated files. We can probably live with that for now.

Agreed.

>
> What we really needs is a preinst but the one we have is really a
> preunpack :/.
>
> Ultimately, I think we need to rename the preinst to preunpack and add a
> real preinst...

I'll keep digging.

Cheers,

Bruce

>
> Cheers,
>
> Richard
>

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Richard Purdie]

On Mon, 2013-10-07 at 11:20 -0400, Bruce Ashfield wrote:
>  I had it slightly wrong. Try:
> >
> > kernelheaders_sstate_postinst () {
> >   	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
> >   	then
> >   		( cd ${KERNEL_SRC_PATH};
> >   		  oe_runmake scripts
> >   		)
> >   	fi
> >   }
> >
> > since the files are actually installed at this point, therefore we
> > operate on the final location.
> 
> That's the kicker, I can't get the right variable to find the final
> location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate
> on it directly. When things were runing in the sysroot_append, the
> kernel src was staged, and then operated on, then it makes it into the
> sysroot. Here, we could operate on the STAGING_KERNEL, which is in the
> sysroot, but stripped of the scripts. Perhaps that is the answer, but
> I need to confirm that scripts installed in that location would be
> available to the out of tree module builds that are looking for modpost
> and friends.

Guessing again (third time lucky?),

cd ${STAGING_DIR_KERNEL};

?

Cheers,

Richard

Re: [PATCH 1/1] kernel: restore scripts in the sysroot

[Bruce Ashfield]

On 13-10-07 12:18 PM, Richard Purdie wrote:
> On Mon, 2013-10-07 at 11:20 -0400, Bruce Ashfield wrote:
>>   I had it slightly wrong. Try:
>>>
>>> kernelheaders_sstate_postinst () {
>>>    	if [ "${BB_CURRENTTASK}" = "populate_sysroot" -o "${BB_CURRENTTASK}" = "populate_sysroot_setscene" ]
>>>    	then
>>>    		( cd ${KERNEL_SRC_PATH};
>>>    		  oe_runmake scripts
>>>    		)
>>>    	fi
>>>    }
>>>
>>> since the files are actually installed at this point, therefore we
>>> operate on the final location.
>>
>> That's the kicker, I can't get the right variable to find the final
>> location, KERNEL_SRC_PATH is set to /usr/src/kernel, so we can't operate
>> on it directly. When things were runing in the sysroot_append, the
>> kernel src was staged, and then operated on, then it makes it into the
>> sysroot. Here, we could operate on the STAGING_KERNEL, which is in the
>> sysroot, but stripped of the scripts. Perhaps that is the answer, but
>> I need to confirm that scripts installed in that location would be
>> available to the out of tree module builds that are looking for modpost
>> and friends.
>
> Guessing again (third time lucky?),
>
> cd ${STAGING_DIR_KERNEL};

Yah, that's where it lives. I'm building now and trying to validate Khem's
use case.

Bruce

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