On Thu, Aug 11, 2022 at 1:26 PM Jose Quaresma <quaresma.j...@gmail.com> wrote:
>
>
>
> Bruce Ashfield <bruce.ashfi...@gmail.com> escreveu no dia quinta, 11/08/2022
> à(s) 18:06:
>>
>> On Thu, Aug 11, 2022 at 12:18 PM Jose Quaresma <quaresma.j...@gmail.com>
>> wrote:
>> >
>> > When the kernel is rebuild or some of they tasks change the
>> > kernel modules is not rebuild as well and will comes from
>> > the sstate-cache.
>> >
>> > [YOCTO #14885] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14885
>> >
>> > Signed-off-by: Jose Quaresma <jose.quare...@foundries.io>
>> > ---
>> > meta/classes/module.bbclass | 2 ++
>> > 1 file changed, 2 insertions(+)
>> >
>> > diff --git a/meta/classes/module.bbclass b/meta/classes/module.bbclass
>> > index a09ec3ed1e..d377a08bc6 100644
>> > --- a/meta/classes/module.bbclass
>> > +++ b/meta/classes/module.bbclass
>> > @@ -1,5 +1,7 @@
>> > inherit module-base kernel-module-split pkgconfig
>> >
>> > +DEPENDS += "virtual/kernel"
>>
>> There's already a dependency on virtual/kernel:do_shared_workdir() through
>> module-base.bbclass and the make-mod-scripts dependency.
>
>
> I know that and imo the make-mod-scripts need to be cleaned up a bit as well
> It is compile the the code do_configure and as a dependency in
> "virtual/kernel:do_compile_kernelmodules"
Right. It doesn't save much, but being able to start dependent tasks even
that bit sooner has proven to be a win. We get plenty of complaints about
the kernel being a bottleneck, which is what lead to the finer dependency.
> for they do_compile anyway this is another history and I will submit some
> patch when finished.
> Another thing that I have in my mind is to make the make-mod-scripts a
> native recipe because they
> don't build anything for the target.
>
make-mod-scripts is a bit strange indeed, it sits somewhere in the middle, it
does use the target compiler, etc, for some tests that the kernel fires as part
of even the scripts and preparation. Which is why it hasn't been -native only
up until now .. it isn't out of the question that we could use it in
more of a cross
friendly way (there are some really old bugs/enhancements around that topic).
It might be worth a try, but if it isn't breaking anything .. I tread
very carefully
around the kernel dependencies, shared-workdir and the scripts. We've had
many subtle race conditions and other hard to debug issues.
>>
>>
>> And that dependency was a change to this:
>>
>> -# This is instead of DEPENDS = "virtual/kernel"
>> -do_configure[depends] += "virtual/kernel:do_compile_kernelmodules"
>>
>> i.e. we've always had a finer grained dependency than what is being
>> proposed here.
>>
>> We need to understand why that shared_workdir() dependency isn't
>> doing the job any more, and if there's no way to fix it .. then going back
>> to the older compile dependency is still lighter weight than depending
>> on virtual/kernel (and the default of do_prepare_recipe_sysroot).
>
>
> I can do another round in order to change another task, other than the
> shared_workdir,
> that I think will do the same i.e: get the modules from the sstate-cache.
> I suspect this is unrelated to the task shared_workdir.
>
> Thanks for the feedback and your time.
I can dig into it more as well, I'll see what I can find in some local builds.
Bruce
>
> Jose
>
>>
>>
>> It must (could?) be something with the shared workdir changing the
>> interactions.
>>
>> Bruce
>>
>> > +
>> > EXTRA_OEMAKE += "KERNEL_SRC=${STAGING_KERNEL_DIR}"
>> >
>> > MODULES_INSTALL_TARGET ?= "modules_install"
>> > --
>> > 2.37.1
>> >
>> >
>> >
>> >
>>
>>
>> --
>> - Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end
>> - "Use the force Harry" - Gandalf, Star Trek II
>
>
>
> --
> Best regards,
>
> José Quaresma
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#169262):
https://lists.openembedded.org/g/openembedded-core/message/169262
Mute This Topic: https://lists.openembedded.org/mt/92962048/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
