[linux-yocto] Organization of Cfg/Features

[Darren Hart]

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?

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

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

--
Darren