[yocto] kernel-devsrc used to be full source - not the case since thud

Thu May 23 09:23:15 PDT 2019

On Thu, May 23, 2019 at 12:20 PM Andrei Gherzan <andrei at gherzan.ro> wrote:

>
> On 23/05/2019 17.11, Bruce Ashfield wrote:
>
>
>
> On Thu, May 23, 2019 at 11:24 AM Andrei Gherzan <andrei at gherzan.ro> wrote:
>
>> On 23/05/2019 16.10, Bruce Ashfield wrote:
>>
>>
>>
>> On Thu, May 23, 2019 at 11:00 AM Andrei Gherzan <andrei at gherzan.ro>
>> wrote:
>>
>>>
>>> On 23/05/2019 15.39, Bruce Ashfield wrote:
>>>
>>>
>>>
>>> On Thu, May 23, 2019 at 10:32 AM Bruce Ashfield <
>>> bruce.ashfield at gmail.com> wrote:
>>>
>>>>
>>>>
>>>> On Thu, May 23, 2019 at 9:56 AM Andrei Gherzan <andrei at gherzan.ro>
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> This might have been discussed before. I couldn't find a relevant
>>>>> thread, but if it is so, just link me to it.
>>>>>
>>>>> Since thud, more specific since
>>>>>
>>>>> commit 9af0f1a46bbb6ad9ee8b35957251f4aa826b023f
>>>>> Author: Bruce Ashfield <bruce.ashfield at windriver.com>
>>>>> Date:   Sat Aug 18 22:50:44 2018 -0400
>>>>>     kernel-devsrc: restructure for out of tree (and on target) module
>>>>> builds
>>>>>
>>>>> ... we switched from a recipe that was deploying the entire source code
>>>>> to one that provides mainly the kernel headers (but not only). This
>>>>> change broke people expectations of this recipe while the description
>>>>> is
>>>>> also confusing: "Development source linux kernel. When built, this
>>>>> recipe packages the \source of the preferred virtual/kernel provider
>>>>> and
>>>>> makes it available for full kernel \development or external module
>>>>> builds".
>>>>>
>>>>> If size is not a problem (which can be the case when you compile on a
>>>>> builder for example and deploy only a OOT kernel module through other
>>>>> means), the full kernel source was a painless experience where things
>>>>> like
>>>>>
>>>>> commit a9471601fedd1f5087304eaa5fd39b98ae220313
>>>>> Author: Bruce Ashfield <bruce.ashfield at windriver.com>
>>>>> Date:   Thu Aug 30 09:45:41 2018 -0400
>>>>>     kernel-devsrc: fix arm/arm64 target module build
>>>>>
>>>>> ... would not appear. I understand the size impact on target and for
>>>>> those cases, continuously maintaining this recipe with new
>>>>> files/resources needed from the kernel, makes sense. So my proposal is
>>>>> to have two recipes, for example kernel-devsrc and kernel-fullsrc
>>>>> (kernel-src etc.) so people can choose what they need/want
>>>>> deploying/using. Or even have another devsrc provider. I'm open to any
>>>>> implementation detail. I'd just want to have an option for a full
>>>>> kernel
>>>>> source recipe.
>>>>>
>>>>
>>>> This is already planned, and hidden in bugzilla somewhere. I'll have
>>>> some new kernel packaging
>>>> options available for the fall release.
>>>>
>>>
>>> It looks like the bugs that I was using for development were finally
>>> moved to resolved (they were a bit old, and contained collected information
>>> on various kernel packaging options .. my searching of bugzilla isn't
>>> turning it up at the moment). So I just created a new bug to track the
>>> development for 2.8.
>>>
>>> The issue with the multiple kernel source providers is really about test
>>> cycles. The smaller devsrc is for on-target module development and builds
>>> against the exported uapi headers, and that is what the nightly / automated
>>> tests will use. We had issues with both the amount of time it took to
>>> package the entire source, and the amount of space that it took up on the
>>> images. Hence the creation of devsrc.
>>>
>>> With new kernel-source and kernel-headers packages (the working names),
>>> they are really provided as references to the running kernel, and will
>>> largely be an exercise left up to the developer to use them as they want.
>>>
>>> Right. So is there anything that holds us from creating two recipes -
>>> one for what we currently have and one for what we used to have pre-thud -
>>> find some pretty names and start from that? I'm asking just in case I'm
>>> missing any internal architecture discussions or so.
>>>
>>
>> In some other non-core layer ? Sure :D The pre-thud copying of the kernel
>> source was a disaster and needed to be killed with fire, as it was. It was
>> all special cases and I commonly needed to fight with it. What you see in
>> the current devsrc is not an invention from Yocto, it is based on the
>> redhat spec files, and also (a bit) on some of the debian packaging of
>> minimal source.
>>
>> I am aware of all the other distros having the similar approach (and they
>> do this dance for disk space optimization) but I don't understand what were
>> all the special cases you had to fight against? The recipe was barely
>> touched in years. For example there is only one commit on it in 2017.
>>
>
> There were corner cases popping up with architectures and the newer
> kernels. I had inflight changes that were tweaking the nasty find commands,
> etc, trying to get everything we needed, minimize the time spent copying
> and avoiding QA errors due to cross arch artifacts popping in. Let's just
> say, I'm not copying and pruning the same way in a plainer "kernel-source"
> package. Since it isn't installed by default, and is opt-in, it doesn't
> have to be quite so careful on those fronts.
>
>
>
>>
>> So no, I'd rather not restore the mess that was the pre-thud devsrc in
>> any form.
>>
>>
>>> And about test cycles, I'm not sure I understand why having a provider
>>> vs having two separate recipes impact automated tests. In both cases you
>>> will select whatever you want to test - by using a specific recipe or by
>>> setting a preferred provider (I don't have a strong opinion here but I was
>>> just curious about the time impact on automated tests).
>>>
>>
>> If it goes into core, we would need to run a full set of tests against it
>> to make sure that it supported development tasks. That would mean on target
>> kernel module builds, as well as potential some new cases given that the
>> full source is available (i.e. kernel rebuild). We already do that for
>> kernel-devrsc, adding multiple providers of something similar means that
>> we'd then have to test the multiple providers against all the
>> architectures, across the actively supported reference kernels in any given
>> release .. something always breaks, so then I'm on the hook for sorting
>> through all the issues (devsrc was not bug free in its previous form).
>> Given the amount of test cycles available, that's not necessarily a trivial
>> thing to add. In the end, it would be up to Richard if thinks something
>> like multiple provides are a good thing, and to commit the test
>> resources/cycles to them.
>>
>> I see. You were comparing something else. That makes sense.
>>
>>
>>
>>
>>
>>> Replying to the other email (this thread was forked). We have maintained
>>> a similar kernel headers approach for a couple of years now. And many times
>>> we found ourselves in the situation where something had to be
>>> added/removed/checked - that was either kernel fork specific or something
>>> that was added due to kernel updates. And this loop of fixes here and there
>>> was obviously completely resolved by just using the "old" kernel-devsrc
>>> which always had "everything" in. A good example is commit
>>> a9471601fedd1f5087304eaa5fd39b98ae220313 I'm mentioning above. This kind of
>>> stuff will always be needed - or at least in our experience was a pretty
>>> often loop (when you try to support one kernel headers recipe against tens
>>> of BSPs, you'll need cases, quirks and so on).
>>>
>> Those small tweaks really are trivial, I don't consider them to be a big
>> load. The advantages of the smaller footprint package have outweighed any
>> tuning we've done since things switched over.
>>
>> Again, I 100% understand the space advantage. I'm trying to see if there
>> are any other advantages at all. In a world with infinite disk space :D
>>
>
> Nothing super dramatic :D The curated / whitelist approach does make sure
> that nothing new slips into the package until we've tested and ok'd it
> (with the downsides you are pointing out) .. so we have an easier route to
> patch / workaround issues as they pop up (I remember before uapi and hand
> sanitizing the kernel headers .. and wouldn't want to be that extreme ever
> again).
>
> But I completely agree, having a simple, full copy of the source for
> situations where build/packaging time or diskspace are not a requirement is
> a good thing. I'll sort through the last symlink / provider issues and get
> something out ASAP.
>
> Thanks Bruce. Would you please CC me when you push that? Just to make sure
> I don't miss it.
>

Absolutely. I'll make sure you are copied.

Bruce

> --
> Andrei Gherzan
> gpg: rsa4096/D4D94F67AD0E9640 | t: @agherzan
>
>

-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end
- "Use the force Harry" - Gandalf, Star Trek II
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20190523/c5e409c5/attachment-0001.html>