On 2/10/14, 8:41, "Bruce Ashfield" <bruce.ashfi...@windriver.com> wrote:
>On 14-02-07 04:48 PM, Darren Hart wrote: >> On 2/7/14, 13:37, "Bruce Ashfield" <bruce.ashfi...@windriver.com> wrote: >> >>> On 2/7/2014, 4:24 PM, Darren Hart wrote: >>>> On 2/7/14, 13:16, "Tom Zanussi" <tom.zanu...@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 _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto