[OE-core] [PATCH] kernel.bbclass: Fix do_shared_workdir task ordering

Bruce Ashfield bruce.ashfield at gmail.com
Tue Aug 11 13:11:20 UTC 2015


On Tue, Aug 11, 2015 at 9:06 AM, Bruce Ashfield
<bruce.ashfield at gmail.com> wrote:
> On Tue, Aug 11, 2015 at 8:47 AM, Otavio Salvador
> <otavio.salvador at ossystems.com.br> wrote:
>> On Tue, Aug 11, 2015 at 12:23 AM, Bruce Ashfield
>> <bruce.ashfield at gmail.com> wrote:
>>> On Mon, Aug 10, 2015 at 11:21 AM, Stefan Müller-Klieser
>>> <s.mueller-klieser at phytec.de> wrote:
>>>> commit 02d0a003d60326 [kernel.bbclass: Fix race condition] has surfaced
>>>> a bug in the generation of the shared_workdir. The task
>>>> do_compile_kernelmodules adds the exported symbols of the kernel modules
>>>> to the Module.symvers. By creating the shared_workdir before the modules
>>>> are compiled, the symbols of the modules are missing in the
>>>> shared_workdir. Subsequent external module builds will not include the
>>>> ABI CRC of functions exported in modules. Modprobe will fail to load the
>>>> external module if CONFIG_MODVERSIONS is enabled.\
>>>
>>> Have you seen our bug: https://bugzilla.yoctoproject.org/show_bug.cgi?id=8127 ?
>>>
>>> It's new .. so probably not.
>>>
>>> The significant issue with this, is that we are now forcing anyone
>>> that needs the
>>> shared workdir artifacts to build kernel modules.
>>>
>>> That's performance issue for many workflows.
>>>
>>> I had some changes where I was working to short cut parts of the process, but
>>> they turned out to miss a few corner cases.
>>>
>>> We need to do more thinking on this one, before we can bring in a change like
>>> this .. since avoiding that overhead is something valuable.
>>
>> I agree that performance is important but correctness seems more
>> valuable for me. I think the optimization can come as a subsequent
>> patch ...
>
> Let's disagree on this point.
>
> There's time to get this right. We have a bug to track it, so we wont'
> release with
> the active bug, and this only hits a very tiny set of users.
>
> So we are going to step back and try and fix this right.

I hit send too soon. I have a suggestion in the bug already, so it isn't like
we are talking about letting this sit for weeks.

History shows that we are very unlikely to loop back and fix the performance
of perf or other builds once the change goes in. So in the absence of
other concrete suggestions, looking into some other small changes is a good
use of time.

Cheers,

Bruce


>
> Bruce
>
>>
>> --
>> Otavio Salvador                             O.S. Systems
>> http://www.ossystems.com.br        http://code.ossystems.com.br
>> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>
>
>
> --
> "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"



More information about the Openembedded-core mailing list