On 1/11/22 03:27, Richard Purdie wrote:
On Mon, 2022-01-10 at 16:42 -0800, Saul Wold wrote:
On 1/8/22 11:27, Bruce Ashfield wrote:
On Fri, Jan 7, 2022 at 6:19 PM Richard Purdie
<[email protected]
<mailto:[email protected]>> wrote:
On Fri, 2022-01-07 at 13:24 -0800, Saul Wold wrote:
> Move the do_strip() functionality to a more common location in the
> package split_and_strip_files() flow. This makes it possible for the
> extended packaging data to be generated correctly for the kernel and
> kernel modules. The KERNEL_IMAGE_STRIP_EXTRA_SECTIONS is reused in
> the runstrip() part of package stripping.
>
> Signed-off-by: Saul Wold <[email protected]
<mailto:[email protected]>>
> ---
> meta/classes/kernel.bbclass | 35 +++--------------------------------
> 1 file changed, 3 insertions(+), 32 deletions(-)
As I mentioned in previous mails, I think this will mean the
do_deploy output
will change and become unstripped which may cause a problem for some
platforms.
We likely need to keep a strip task but call the new strip function
from it?
I personally think this is a reasonable direction apart from that
though, at
least in principle.
Agreed. It looks ok to me as well, with us making sure that do_deploy
can remain as it was.
I have been looking into this and realized it's maybe a little more
complex since the do_sizecheck() needs to run also before do_deploy.
Currently, I believe the ordering is:
do_compile()
do_compile_kernelmodules()
do_kernel_linux_images()
do_strip()
do_sizecheck()
do_install
do_package()
do_packagedata()
do_deploy()
If I move the strip() process to package, I also have to move when
do_sizecheck() runs. As you mention we need to keep what gets deployed
to be the same with and without the package split_and_strip_files().
I understand what your talking about having the vmlinux image (which is
the one getting stripped) is the same before and after this changeset, I
don't think it's an issue of the deployed vmlinux being un-stripped but
the vmlinux being stripped in the deploy dir.
We can't really call the package.bbclass strip from the kernel bbclass
since it's part of the package process and called in a multiprocess() way.
This bit puzzles me. Why can't we manually call the function from kernel
bbclass? It might not be particularly nice given the multiprocess bits but I'm
sure it can be done and likely the lesser of several evils. If it works in a
multiprocess context, it should work without? (the other way around is much
harder).
I might not of explained myself well, since I did not mention the
gathering of debug info (extended packagedata) occurs during the
do_package() phase. Yes, I can use the runstrip() function from
oe.package in kernel.bbclass, but it still means the kernel image is
stripped by the time it gets to the do_package when we want to gather
the debuginfo, but can't from the already stripped kernel image.
It's a task ordering issue in combination with what happens in the
split_and_strip_files() to get the extended packagedata that the
create-spdx bbclass then uses.
The kernel do_strip() happens on the vmlinux image in B, while the
package stripping happens in the PKGD directory, while do_deploy goes
back to B for the kernel image (KERNEL_IMAGETTYPES) which might not be
the vmlinux. It's a twisty little process with back and forth. I think
this is where I got a little confused also, I thought do_deploy was from
either D (WORKDIR/image) until I re-read the run.do_deploy script
itself! (my bad).
I could add special handling in the kernel to do the strip/split
Hope that makes better sense.
Sau!
Cheers,
Richard
--
Sau!
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160464):
https://lists.openembedded.org/g/openembedded-core/message/160464
Mute This Topic: https://lists.openembedded.org/mt/88271781/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
