[linux-yocto] [PATCH 02/13] ktypes: add extended ktype

[Paul Gortmaker]

[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 <california.l.sullivan at intel.com>
> >>> ---
> >>>   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
> >>> linux-yocto at yoctoproject.org
> >>> https://lists.yoctoproject.org/listinfo/linux-yocto
> >
>