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. -- Darren _______________________________________________ linux-yocto mailing list linux-yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/linux-yocto