[linux-yocto] Organization of Cfg/Features

[Bruce Ashfield]

On 2/7/2014, 4:24 PM, Darren Hart wrote:
> On 2/7/14, 13:16, "Tom Zanussi" <tom.zanussi at intel.com> wrote:
>
>> On Fri, 2014-02-07 at 12:53 -0800, Darren Hart wrote:
>>> I'm working on adding support for a specific SoC (Bay Trail
>>> specifically).
>>> I have a few things that it incorporates, Designware I2C, SPI,
>>> I2S/Sound,
>>> it needs LPSS, some PWM bits, the i915 driver, etc.
>>>
>>> The i915 is separated out already, the others, not so much. I'm
>>> struggling
>>> with where to put them and would appreciate your thoughts.
>>>
>>> I could add Designware configs to a general fragment for each of I2C and
>>> SPI. Same for the UART. I looked at the sound fragment, but it says it's
>>> for OSS ?!?! And doesn't include things like INTEL HDA, so it's not
>>> particularly useful.
>>>
>>> I considered adding a cfg/SoC directory, but that might as well be in
>>> BSP
>>> and I was trying to make it more reusable.
>>>
>>> And that's the final option, I could create a BSP that targets just this
>>> SoC and include that in the more generic intel-core* BSPs. My concern
>>> with
>>> this is the amount of redundancy that is likely to proliferate over
>>> time.
>>>
>>> The current set of cfg and features is already fairly difficult to
>>> navigate.
>>>
>>> And on that, my second topic.
>>>
>>> As I understand it, the accepted best practice is to put cfg-only
>>> fragments under cfg while things requiring patches should go under
>>> features.... We've been lax if that's the case and we have a fair amount
>>> of cleanup to do.
>>>
>>
>> If that's the case then cfg will get very crowded, since most of the
>> stuff in features is cfg-only.  For that matter, since we're examining
>> things afresh, why have patches in features at all - why not just put
>> all the code (patches) in the machine branches?  In that case, we only
>> have one location, cfg/ (or features/, whichever)...
>
> I think this too has grown organically. However, when patches are under
> heavy development, trying to maintain them in a git feature branch quickly
> becomes tiresome with rebases and such.
>
>>
>>> The organization has deteriorated over time as well. I'm wondering if we
>>> should have a meta-cleanup-week where we all take a block and reorg it
>>> and
>>> the impacted BSPs to some agreed upon standard in time for the
>>> linux-yocto-dev conversion to a named release. Specifically I'm
>>> wondering
>>> if we should create a hierarchy in cfg that parallels the Kconfig
>>> hierarchy. Drivers/net/ethernet, for example. We could cap it at 2
>>> layers
>>> to keep it from getting overly granular. This seems to me that it would
>>> provide some direction as to how to create fragments as well as make
>>> them
>>> easier to find and reuse.
>>>
>>> Thoughts?
>>>
>>
>> A cleanup would definitely be in order - I've noticed while providing
>> fragments for tracing and profiling for another project that there's a
>> lot of overlap and even missing bits where there should be something.
>> To be expected having grown organically, but we can probably do better
>> now with hindsight..
>>
>> Tom
>
> Right, this wasn't a criticism but rather an observation that it's
> probably time to get out the pruners and perform some deferred maintenance.

Agreed. No criticism was taken here, it is what it is. A cleanup gets a +1
from me.

Bruce

>
> --
> Darren
>
>
>
> _______________________________________________
> linux-yocto mailing list
> linux-yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>