[linux-yocto] Organization of Cfg/Features

Tom Zanussi tom.zanussi at intel.com
Fri Feb 7 13:16:18 PST 2014

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

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


More information about the linux-yocto mailing list