On 14-02-10 12:56 PM, Darren Hart wrote:
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?
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
_______________________________________________
linux-yocto mailing list
linux-yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/linux-yocto
