On 2015-12-03 10:49, Otavio Salvador wrote: > On Thu, Dec 3, 2015 at 4:43 PM, Stefan Agner <[email protected]> wrote: >> On 2015-12-03 10:28, Otavio Salvador wrote: >>> On Thu, Dec 3, 2015 at 4:24 PM, Stefan Agner <[email protected]> wrote: >>>> On 2015-12-03 10:17, Otavio Salvador wrote: >>>>> I prefer SoC family as it makes easier for end customers to customized >>>>> it without need to override the compatibility set in a bbappend. As >>>>> this provides a SoM it is common it ends being used in a custom >>>>> carrier board and eventually a new machine file in a customer layer >>>>> can reuse the recipe. >>>> >>>> This is a good point, so e.g. if somebody would need to alter the >>>> machine and would create a machine like apalis-imx6-mycarrier. We >>>> actually would need another inheritance like SoC, for boards/carrier >>>> boards... >>> >>> Yes but this can be add on the machine itself. The compatibile would >>> demand a bbappend usually. >> >> How can this be added? By using the module name "apalis-imx6" as >> SOC_FAMILY? >> >> In that case, a COMPATIBLE on module level would be good enough (e.g. as >> it is now, just apalis/colibri-imx6 would be the module level). > > Yes; so it is added to the MACHINEOVERRIDES and ends being used as > fallback. This is done for Wandboard in the past and I think is still > used for OLinuxIno boards. >
I see. >> However, so far customization needs on machine level hasn't really come >> up so far. Customers typically use our default machines, and customize >> the image by other means... > > Yes but I see no problem in making it easier for end-users, do you? It would be a big change, since all machines are now called according to the module name. I guess you can't use the same name of a SOC level and a machine... Hence we would have to rename all machines... taking care of Documentation, etc... I guess we need to discuss this internally and look at things a little closer to understand the implications. Maybe we can postpone such a change? -- Stefan -- _______________________________________________ meta-freescale mailing list [email protected] https://lists.yoctoproject.org/listinfo/meta-freescale
