[linux-yocto] linux-yocto Digest, Vol 20, Issue 8
Ong, Boon Leong
boon.leong.ong at intel.com
Mon Feb 10 17:18:54 PST 2014
> -----Original Message-----
> From: linux-yocto-bounces at yoctoproject.org [mailto:linux-yocto-
> bounces at yoctoproject.org] On Behalf Of linux-yocto-
> request at yoctoproject.org
> Sent: Tuesday, February 11, 2014 2:53 AM
> To: linux-yocto at yoctoproject.org
> Subject: linux-yocto Digest, Vol 20, Issue 8
>
> Send linux-yocto mailing list submissions to
> linux-yocto at yoctoproject.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.yoctoproject.org/listinfo/linux-yocto
> or, via email, send a message with subject or body 'help' to
> linux-yocto-request at yoctoproject.org
>
> You can reach the person managing the list at
> linux-yocto-owner at yoctoproject.org
>
> When replying, please edit your Subject line so it is more specific than "Re:
> Contents of linux-yocto digest..."
>
>
> Today's Topics:
>
> 1. [PATCH 0/1] meta: valleyisland-io: remove PCI mode
> configurations from cfg files (rebecca.swee.fun.chang at intel.com)
> 2. [PATCH 1/1] meta: valleyisland-io: remove PCI mode LPSS
> device config (rebecca.swee.fun.chang at intel.com)
> 3. Re: Organization of Cfg/Features (Bruce Ashfield)
> 4. Re: Organization of Cfg/Features (Darren Hart)
> 5. Re: Organization of Cfg/Features (Bruce Ashfield)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Mon, 10 Feb 2014 21:08:09 +0800
> From: rebecca.swee.fun.chang at intel.com
> To: linux-yocto at yoctoproject.org
> Cc: Chang, Rebecca Swee Fun <rebecca.swee.fun.chang at intel.com>
> Subject: [linux-yocto] [PATCH 0/1] meta: valleyisland-io: remove PCI
> mode configurations from cfg files
> Message-ID: <cover.1392037593.git.rebecca.swee.fun.chang at intel.com>
>
> From: "Chang, Rebecca Swee Fun" <rebecca.swee.fun.chang at intel.com>
>
> Hi,
>
> This is a pull request for an update on valleyisland-io cfg files.
>
> Valley Island LPSS devices are supporting both ACPI and PCI mode
> enumeration. In order for users to easily enable ACPI mode enumeration, we
> moved the PCI mode configs out into recipe level.
>
> By default, kernel recipe will enable PCI mode. When user found a need to
> enable ACPI mode, they can refer to README in meta-valleyisland for further
> enabling steps.
>
> Please help to pull update into linux-yocto-3.8 meta branch
>
> Thanks.
>
> Rebecca
>
> The following changes since commit
> f87180481b12aebd16b9234d922d5f4a25a32dca:
>
> meta: rename scc files for valleyisland bsp (2014-02-04 09:09:17 -0500)
>
> are available in the git repository at:
>
> git://git.yoctoproject.org/linux-yocto-contrib rebeccas/meta-update
> http://git.yoctoproject.org/cgit.cgi/linux-yocto-
> contrib/log/?h=rebeccas/meta-update
>
> Chang, Rebecca Swee Fun (1):
> meta: valleyisland-io: remove PCI mode LPSS device config
>
> .../kernel-cache/features/valleyisland-io/valleyisland-io.cfg | 9 ---------
> 1 file changed, 9 deletions(-)
>
> --
> 1.7.10.4
>
>
>
> ------------------------------
>
> Message: 2
> Date: Mon, 10 Feb 2014 21:08:17 +0800
> From: rebecca.swee.fun.chang at intel.com
> To: linux-yocto at yoctoproject.org
> Subject: [linux-yocto] [PATCH 1/1] meta: valleyisland-io: remove PCI
> mode LPSS device config
> Message-ID:
> <b84d486936018bf5ef985ecb0ada62ead315dcd0.1392037593.git.reb
> ecca.swee.fun.chang at intel.com>
>
>
> From: "Chang, Rebecca Swee Fun" <rebecca.swee.fun.chang at intel.com>
>
> Remove PCI mode LPSS deivce configurations. These
> configurations are moved into a patch in recipe layer
> in order for Valley Island LPSS devices to support both
> ACPI mode and PCI mode enumeration.
>
> Signed-off-by: Chang, Rebecca Swee Fun
> <rebecca.swee.fun.chang at intel.com>
> ---
> .../kernel-cache/features/valleyisland-io/valleyisland-io.cfg | 9 ---------
> 1 file changed, 9 deletions(-)
>
> diff --git a/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg
> b/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg
> index 983315b..a505cbd 100644
> --- a/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg
> +++ b/meta/cfg/kernel-cache/features/valleyisland-io/valleyisland-io.cfg
> @@ -1,12 +1,3 @@
> -# By default, enable PCI mode enumeration
> -# change to "n" if to disable PCI mode
> -CONFIG_BYT_LPSS_BRD=y
> -CONFIG_GPIO_BYT_DEVICE=y
> -CONFIG_I2C_DESIGNWARE_PCI=y
> -CONFIG_SPI_PXA2XX_PCI=y
> -CONFIG_DW_DMAC_PCI=y
> -CONFIG_PWM_LPSS_PCI=y
> -
These configs should be moved from here to valleyisland-io-pci.cfg, then linked into
valleyisland-io-pci.scc. By default, meta-valleyisland/recipes-kernel/linux/linux-yocto_3.8.bbappend
will use both valleyisland-io-pci.scc & valleyisland-io.scc since the default setting of the BIOS
is PCI enumeration.
> #GPIO Support
> CONFIG_GPIOLIB=y
> CONFIG_GPIO_SYSFS=y
> --
> 1.7.10.4
>
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 10 Feb 2014 11:41:13 -0500
> From: Bruce Ashfield <bruce.ashfield at windriver.com>
> To: Darren Hart <dvhart at linux.intel.com>, Tom Zanussi
> <tom.zanussi at intel.com>
> Cc: linux-yocto <linux-yocto at yoctoproject.org>
> Subject: Re: [linux-yocto] Organization of Cfg/Features
> Message-ID: <52F90129.40500 at windriver.com>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> 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.
>
> .. 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".
>
> 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.
>
> Bruce
>
> >
> > If we can agree on this (or after something along these lines) then we can
> > break it up into blocks and have a meta-sprint (haha) and quickly make
> > some progress. We've tried for a couple years now to incrementally
> improve
> > this and it just hasn't happened. I think we need a concerted combined
> > effort to make this happen.
> >
> > --
> > Darren
> >
> >
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 10 Feb 2014 09:56:03 -0800
> From: Darren Hart <dvhart at linux.intel.com>
> To: Bruce Ashfield <bruce.ashfield at windriver.com>, Tom Zanussi
> <tom.zanussi at intel.com>
> Cc: linux-yocto <linux-yocto at yoctoproject.org>
> Subject: Re: [linux-yocto] Organization of Cfg/Features
> Message-ID: <CF1E5187.6B383%dvhart at linux.intel.com>
> Content-Type: text/plain; charset="US-ASCII"
>
> 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
>
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 10 Feb 2014 13:52:23 -0500
> From: Bruce Ashfield <bruce.ashfield at windriver.com>
> To: Darren Hart <dvhart at linux.intel.com>, Tom Zanussi
> <tom.zanussi at intel.com>
> Cc: linux-yocto <linux-yocto at yoctoproject.org>
> Subject: Re: [linux-yocto] Organization of Cfg/Features
> Message-ID: <52F91FE7.2010603 at windriver.com>
> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
>
> On 14-02-10 12:56 PM, Darren Hart wrote:
> > 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?
>
> 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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/linux-yocto
>
>
> End of linux-yocto Digest, Vol 20, Issue 8
> ******************************************
More information about the linux-yocto
mailing list