[yocto] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1649

[Brian Lloyd]

FYI: new user stuck having to implement a bps found the description below about the extra demarcation between groups and partitions helpful.   Now if only I knew which branches were partitions and which where groups...


Brian A Lloyd

On Aug 21, 2012, at 12:14 PM, Darren Hart <darren.hart at intel.com> wrote:

> On 08/20/2012 09:13 PM, Bruce Ashfield wrote:
> 
>>>> +Kernel types (ktypes) are the highest level policy containers and represent
>>>> +a significant set of kernel functionality that has been grouped (and named)
>>>> +or partitioned.
>>> 
>>> What are you trying to convey with "partitioned" vs. "grouped" ? The
>>> "or" indicates a functional difference, but it isn't clear what that is
>>> from this reading.
>> 
>> partitioned means that they are really being kept apart since they won't
>> work together (think BFS vs CFS, or grsec vs another security patch). 
>> Grouped
>> just means that you have 15 or 20 things that you want to collectively
>> call a "kernel type" and validate that they work together in a particular
>> configuration. But there's no fundamental incompatibility between these
>> features and others in the system.
>> 
>> It's a hard vs soft partitioning.
>> 
>> Would the expansion that I have above help ?
> 
> Hrm, nah. Let's leave it and address it if someone else raises a
> concern. I might be alone here.
> 
>>>> + - behaviour. A kernel type defines a default behaviour, which is often a
>>> 
>>> behaviour: a kernel type ...
>> 
>> You left my Canadian behaviour .. my spell checker thanks you! Fixed.
> 
> With a UK architect it seemed presumptuous to do otherwise ;-)
> 
>>>> +named category. These typically are included by kernel types, and are not
>>>> +meant to implement a defined functionality or be included multiple times.
>>>> +
>>>> +These often contain bug fixes, backports or other small changes to the kernel
>>>> +tree, and do not typically contain any kernel configuration fragments. patches
>>> 
>>> typically? How can a patch contain a config change?
>> 
>> That just means that a directory called 'patches' vs 'features' wouldn't
>> contain associated config fragments to enable that functionality. But since
>> the system is flexible, there's no reason they can't, so I went with
>> "typically" :) I can clarify.
> 
> Yeah... I think we need to kill config vs feature vs patches and merge
> them together into a single term. Having the three seems to add more
> confusion than information.
> 
> What do you see as the value for maintaining the 3 concepts separately?
> 
>>>> +Config groups are collections of configuration options that when included
>>>> +enable a specific behaviour or functionality. Configuration groups do not
>>>> +contain patches, and can be included multiple times by any other feature or
>>>> +kernel type. The impact of configuration groups is additive, and order
>>>> +matters, since the last included config group can override the behaviour of
>>>> +previous includes.
>>> 
>>> Is this the same thing as "config fragment"? If so, we should pick one
>>> and be consistent. If not, how do they differ?
>> 
>> I was more thinking about the "cfg" subdir and the .scc file that includes
>> a .cfg when I wrote this. The foo.cfg is the config fragment, the named
>> group is the .scc file + the .cfg.
>> 
>> I'm not sure it is worth splitting the hair here. I can just go with
>> configuration fragment. How does that sound ?
> 
> You're right, the config .scc file is not a config fragment, the .cfg
> files are. So a config group includes one or more config fragments. Got it.
> 
> 
>>>> +Note: Depending on the architecture of the meta data, configuration groups
>>>> +can be complete, or partitioned. Complete config groups contain all the
> 
>                    ^ comma should be removed
> 
>>>> +options required to enable functionality, partitioned configurations rely on
>>>> +multiple includes to build up a set of non overlapping options to enable
>>> 
>>> non-overlapping
>>> 
>>>> +functionality. Complete groups are simpler to include, but make it more
>>>> +difficult to remove or disable an option (since it can appear multiple
>>>> +times),
>>> 
>>> If a config fragment includes another one - isn't the end result the same?
>> 
>> which part ? The appear multiple times ? Yes, you can end up with thing
>> via fragments that include others, but not if you've partitioned them
>> all.
> 
> 
> complete.scc
>  include complete.cfg
> 
> complete.cfg
>  CONFIG_A=y
>  CONFIG_B=y
> 
> partitioned.scc
>  include partitioned_a.cfg
>  include partitioned_b.cfg
> 
> partitioned_a.cfg
>  CONFIG_A=y
> 
> partitioned_b.cfg
>  CONFIG_B=y
> 
> This is how I understood your description. Assuming I have this right,
> there is no difference between including compelte.scc or
> partitioned.scc. Each will pull in all the same CONFIG* options and
> modify/overwrite/etc any existing settings in exactly the same way. This
> is what I meant by "same end result".
> 
> I guess what you're saying is the partitioned approach is more modular
> and allows for changing a specific option in one place (CONFIG_A in
> partitioned_a.cfg which will roll up into partitioned.scc) rather than
> having several scc's similar to complete.scc which all need to be
> modidfied to change CONFIG_A.
> 
> That could probably be made clearer.
> 
>>>> +supports and is the typical entry point of a build system to the
>>>> +configuration data of the meta branch.
>>> 
>>> For whatever reason, that reads as very abstract and is rather difficult
>>> to parse. I understand it... but _I_ needed to read it several times,
>>> and I know the system fairly well...
>> 
>> .. I'll try something easier on the head, I was trying to stay out
>> of .scc file syntax, which is probably why it reads hard. Maybe this ?
>> 
>>  The machine is the top-level description of a board, and the hardware
>>  that it supports. A machine/BSP .scc file is found by a build system
> 
> I would stick with machine or BSP, but not confuse the issue by using
> both. In the case of the linux-yocto meta data, the term BSP is more
> discoverable as it maps to the directory name.
> 
>>  to start the processing of a particular machine and kernel type
>>  combination. From the machine description, all the source code changes
>>  (patches, features) and configuration changes that are used to
>>  configure and build the kernel are located.
> 
> It's still a bit round about. How about:
> 
> The BSP .scc files combine the policy from the kernel type with the
> hardware requirements of the machine into a single place. This file
> describes all the source code changes from patches and features and the
> configuration changes that are used to configure and build the kernel.
> 
> 
>> Changes made and pushed to the yocto-kernel-cache, we can continue to 
>> iterate,
>> but this review was very helpful!
> 
> Great. Thanks for doing the write-up Bruce.
> 
> 
> -- 
> Darren Hart
> Intel Open Source Technology Center
> Yocto Project - Linux Kernel
> _______________________________________________
> yocto mailing list
> yocto at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto