[linux-yocto] Organization of Cfg/Features

[Darren Hart]

On 2/7/14, 13:37, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:

>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.

We need to agree on what we *want* it to look like. My suggestion would be:

cfg/
	- Contains a Kconfig-parallel hierarchy of no more than 2 levels
	- scc files are used only for aggregating features
	- No scc file is used to contain a single kconf line

features/
	- Contains development features including patches and cfg fragments to
enable them
	- Every feature is in its own directory
	- I think I'd propose we start with a directory depth of 1 here

If we can agree on this (or after something along these lines) then we can
break it up into blocks and have a meta-sprint (haha) and quickly make
some progress. We've tried for a couple years now to incrementally improve
this and it just hasn't happened. I think we need a concerted combined
effort to make this happen.

--
Darren