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

[Sullivan, California L]

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 <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
>