On 02/08/2016 11:24 AM, Bruce Ashfield wrote: > On 2016-02-07 6:14 PM, Paul Gortmaker wrote: >> [[linux-yocto] [PATCH 02/13] ktypes: add extended ktype] On 04/02/2016 (Thu >> 16:25) California Sullivan wrote: >> >>> The extended ktype enables EMBEDDED, EXPERT, and DEBUG_KERNEL, >>> opening up more kernel options. >> I wonder if adding a ktype is too heavy handed for what we are doing >> here. After all, we are just shuffling config settings and cfg files, >> where historically a ktype reflected a fundamental different base branch >> being used at ground zero (i.e. standard/base vs preempt-rt/base). >> Can this be done as a feature and not a ktype? >> > I know that this has been discussed in the past about why the ktype > was being used, it would be worth summarizing the intent here, so it > can be archived and socialized .. that way we are sure that interested > parties are in agreement (or at least aware). > > It is true that we don't want a lot of ktypes, and that we don't want > a lot of optional fragments being applied via KERNEL_FEATURES to change > a base ktype into something it isn't. > > I'd consider a significantly different kernel configuration and purpose > as grounds for a new ktype, even if it doesn't require a new branch or > set of patches .. and I think that is the intent here.
I think that the differences between the kernels are large enough to warrant being considered a different kernel type. Not including the HIDs, enabling EMBEDDED, EXPERT, and DEBUG_KERNEL toggle over thirty different config options which are not inherently obvious, and cause significant differences in function. That being said, I can see some advantages of having a developer feature instead, and it would not be tons of work to adapt what I have already to make that change. I won't be upset if the consensus is to go with that instead. > >> I'd rather not get into name bike shedding, but at the same time >> "extended" doesn't really convey anything concrete. Looking at what we >> are trying to compartmentalize here, I wonder if "developer" is a better >> fit ; these are all things I'd expect a developer to employ when doing >> their coding and testing, then they get disabled at final deployment. > That's not a bad suggestion. To me, developer does indicate more than > extended as well. > > Naming things sucks, but definitely worth discussing. > > Bruce Agree here on all accounts. Especially the "naming things sucks" part! --- Cal Sullivan > >> P. >> -- >> >>> Signed-off-by: California Sullivan <[email protected]> >>> --- >>> ktypes/extended/extended.cfg | 18 ++++++++++++++++++ >>> ktypes/extended/extended.scc | 10 ++++++++++ >>> 2 files changed, 28 insertions(+) >>> create mode 100644 ktypes/extended/extended.cfg >>> create mode 100644 ktypes/extended/extended.scc >>> >>> diff --git a/ktypes/extended/extended.cfg b/ktypes/extended/extended.cfg >>> new file mode 100644 >>> index 0000000..98f79be >>> --- /dev/null >>> +++ b/ktypes/extended/extended.cfg >>> @@ -0,0 +1,18 @@ >>> +#......................................................................... >>> +# WARNING >>> +# >>> +# This file is a kernel configuration fragment, and not a full kernel >>> +# configuration file. The final kernel configuration is made up of >>> +# an assembly of processed fragments, each of which is designed to >>> +# capture a specific part of the final configuration (e.g. platform >>> +# configuration, feature configuration, and board specific hardware >>> +# configuration). For more information on kernel configuration, please >>> +# consult the product documentation. >>> +# >>> +#......................................................................... >>> + >>> +# >>> +# General setup >>> +# >>> +CONFIG_EXPERT=y >>> +CONFIG_EMBEDDED=y >>> diff --git a/ktypes/extended/extended.scc b/ktypes/extended/extended.scc >>> new file mode 100644 >>> index 0000000..eaa94c8 >>> --- /dev/null >>> +++ b/ktypes/extended/extended.scc >>> @@ -0,0 +1,10 @@ >>> +# Include this kernel type fragment to get the standard features and >>> +# configuration values, as well as extended options through EXPERT, >>> +# EMBEDDED, and DEBUG_KERNEL. >>> + >>> +include ktypes/standard/standard.scc >>> +branch standard >>> + >>> +force kconf non-hardware extended.cfg >>> + >>> +include features/debug/debug-kernel.scc >>> -- >>> 2.5.0 >>> >>> -- >>> _______________________________________________ >>> linux-yocto mailing list >>> [email protected] >>> https://lists.yoctoproject.org/listinfo/linux-yocto > -- _______________________________________________ linux-yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/linux-yocto
