[Re: [linux-yocto] [PATCH 02/13] ktypes: add extended ktype] On 10/02/2016 (Wed 20:37) Sullivan, California L wrote:
> 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. OK, as long as it was discussed and was a conscious choice, then I have no reason to insist it be feature vs. ktype. Just didn't want us to add a ktype by default without considering options. P. -- > > 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
