[linux-yocto] Organization of Cfg/Features

[Bruce Ashfield]

On 14-02-07 04:48 PM, Darren Hart wrote:
> 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:

What you have below was largely the original intent of the structure,
but as we've said, over time as changes have gone upstream not enough
has moved from features -> cfg.

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

I'd leave the door open for some deviations, so I'd change the above
to "should not" vs an absolute statement.

I'm ok with some depth to the structure as well, as long as it isn't too
deep, or set in stone that it must follow the kernel's structure.

Having granular fragments, but collecting .scc files also makes sense
from a usability point of view. Users are free to create their own .scc
files that include the .cfg's, so in the end, we have complete flexibility.

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

The kernel types are still worth separating out into a different bucket,
so don't forget them here. We'd also have ktypes/*, where the definition
of a kernel type is a:

   - A named entry point into the kernel configuration that encompasses
     an entire set of features or behaviour. "small", "realtime", etc,
     being examples.

.. and finally, what about the small, standalone changes and fixes to
the kernel ? They've typically gone under "patches" before, if we want
to unify under features, that is a bit odd "features/patches", but what
about "patches/features/<foo>" instead ? The same thing can be said about
the 'arch' changes, which are at the top level, but could (should), just
move under "patches/arch".

There are also some categories that don't completely map, things like
"bsp", "staging" and "LTSI", and since they are not typically a user 
interface,
they sit right at the top level. I'd consider moving them, but only if
there's a compelling reason.

Bruce

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