[OE-core] [yocto] Move device tree generation from include file to bbclass

[Bruce Ashfield]

On Wed, Apr 15, 2015 at 12:12 PM, Nikolay Dimitrov <picmaster at mail.bg> wrote:
> Hi Bruce,
>
>
> On 04/15/2015 06:26 PM, Bruce Ashfield wrote:
>>
>> On Wed, Apr 15, 2015 at 11:22 AM, Nikolay Dimitrov
>> <picmaster at mail.bg> wrote:
>>>
>>> Hi Bruce,
>>>
>>>
>>> On 04/15/2015 04:13 PM, Bruce Ashfield wrote:
>>>>
>>>>
>>>> On 2015-04-15 08:33 AM, Bach, Pascal wrote:
>>>>>
>>>>>
>>>>> Hi
>>>>>
>>>>
>>>> Adding oe-core, since that's the right place to have a discussion
>>>> like this.
>>>>
>>>>> As ARM now also moved to device tree it look like in future we
>>>>> will have more kernels that are using device tree then ones
>>>>> that are not.
>>>>
>>>>
>>>>
>>>> True, but it has been like this for quite some time now :)
>>>>
>>>>> As far as I understand currently the generation of device
>>>>> trees is controlled via KERNEL_DEVICETREE and is handled in via
>>>>> an include file recipes-kernel/linux/linux-dtb.inc.
>>>>>
>>>>> I was thinking about moving this include into a class so it
>>>>> becomes easier to use. Before I dive into implementing
>>>>> something I would like some feedback from the community.
>>>>
>>>>
>>>>
>>>> The big trick with changing anything like this is compatibility
>>>> with existing recipes. Whatever we do, existing recipes and
>>>> layers shouldn't be broken .. or if they are broken, there
>>>> should be a compelling technical reason to do so.
>>>>
>>>>>
>>>>> I have the following variant in mind.
>>>>>
>>>>> Add the device tree generation to the current kernel.bbclass
>>>>> (or let kernel.bblcass inherit from a kernel-dtb.bbclass).
>>>>> This way all kernels would automatically be DT enabled. The
>>>>> class would check if KERNEL_DEVICETREE is set and generate
>>>>> device trees based on this information. For boards that don't
>>>>> have KERNEL_DEVICETREE set the class would do nothing and the
>>>>> behavior is like before. The advantage I see with this
>>>>> approach is that the only thing a user needs to do is to set
>>>>> KERNEL_DEVICETREE in the board and make sure the device trees
>>>>> are available in the kernel they like to build.
>>>>
>>>>
>>>>
>>>> That's pretty much the experience that most users have now, since
>>>> there's nearly always a kernel recipe created, that recipe
>>>> includes linux-dtb.inc, and sets KERNEL_DEVICETREE.
>>>
>>>
>>>
>>> As far as I understood, Pascal's idea is to remove the need for
>>> user recipes to include linux-dtb.inc, and provide this
>>> functionality via inheritance.
>>
>>
>> That is obvious. My questions are around "why". There's no big
>> technical advantage, and if you remove that existing file, you break
>>  existing recipes. Which means you need to leave a stub in place.
>>
>> So without a technical advantage, it's churn for the sake of churn.
>
>
> Well, removing redundancy and simplifying users' recipes could be
> considered an advantage. Also, as the contents of linux-dtb.inc are
> going to be moved to bbclass, the file can be left empty, later
> maintainers remove the extra line from all users' recipes in following
> commits. I don't see breaking as an option.

And we could argue that having more inherits in the base is a bad
thing for users that have no interest in device trees.

One person's advantage is another's churn. I was looking for technical
advantages or a plan for future features that might leverage this.

Cheers,

Bruce

>
>> Bruce
>>
>>>
>>>> Everything else happens to build and package the device tree.
>>>>
>>>> Was there something specifically that was causing issues with the
>>>> current way of building them ?
>>>>
>>>> Cheers,
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>> I appreciate your feedback?
>>>>>
>>>>> Regards Pascal
>
>
> Kind regards,
> Nikolay



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"