[linux-yocto] Organization of Cfg/Features

[Bruce Ashfield]

On 14-02-10 12:56 PM, Darren Hart wrote:
> On 2/10/14, 8:41, "Bruce Ashfield" <bruce.ashfield at windriver.com> wrote:
>
>> 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.
>
>
> Agreed, I was just focused on cfg and features and was ignoring the rest,
> but while we're at it, yes, we might as well mention the others here too.
>
>>
>> .. 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".
>
> Hrm. If we are enabling something, then I consider these features. If they
> are bug fixes, then they should just be in standard/base right?
>
> I believe you would prefer features went away right? Let git manage the
> sources and cfg/ handle the configuration thereof?

The distinction between "features" and "non features" isn't a feature
branch vs integrated. They were just patch series that together
implement a larger feature (i.e. a cgroup).

Even if the patches sit in a feature directory they've almost always
been integrated into a branch (standard/base or a BSP).

>
> Why do we have non-feature patches outside of the git sources? Is this the
> generation of the tree mechanism?

See above, they really aren't out of tree if they are in features.

Maybe the take-away from this discussion is that we need something that
separates "staged features" or "patches applied at patch time" from the
already integrated features.

>
>> 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.
>
> I'm looking at the user exposed bits here really, which are:
>
> cfg
> feature
> bsp
> ktype
>
> I'd prefer we focus on cfg and feature as growing the scope is just going
> to make this less likely to happen :-)
>
> I do want to understand the patch/ bits though.

The patches are just like features, except they are small and standalone
changes to the tree.

Bruce

>
> --
> Darren
>
>