On Wed, Apr 15, 2015 at 12:12 PM, Nikolay Dimitrov <picmas...@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 >> <picmas...@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" -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core
