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...
toggle quoted message
Show quoted text
Brian A Lloyd
On Aug 21, 2012, at 12:14 PM, Darren Hart <darren.hart@...> wrote:
On 08/20/2012 09:13 PM, Bruce Ashfield wrote:
Hrm, nah. Let's leave it and address it if someone else raises a
partitioned means that they are really being kept apart since they won't
+Kernel types (ktypes) are the highest level policy containers and representWhat are you trying to convey with "partitioned" vs. "grouped" ? The
+a significant set of kernel functionality that has been grouped (and named)
"or" indicates a functional difference, but it isn't clear what that is
from this reading.
work together (think BFS vs CFS, or grsec vs another security patch).
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 ?
concern. I might be alone here.
With a UK architect it seemed presumptuous to do otherwise ;-)
You left my Canadian behaviour .. my spell checker thanks you! Fixed.
+ - behaviour. A kernel type defines a default behaviour, which is often abehaviour: a kernel type ...
Yeah... I think we need to kill config vs feature vs patches and merge
That just means that a directory called 'patches' vs 'features' wouldn't
+named category. These typically are included by kernel types, and are nottypically? How can a patch contain a config change?
+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
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.
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?
You're right, the config .scc file is not a config fragment, the .cfg
I was more thinking about the "cfg" subdir and the .scc file that includes
+Config groups are collections of configuration options that when includedIs this the same thing as "config fragment"? If so, we should pick one
+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
and be consistent. If not, how do they differ?
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 ?
files are. So a config group includes one or more config fragments. Got it.
^ comma should be removed
+Note: Depending on the architecture of the meta data, configuration groups
+can be complete, or partitioned. Complete config groups contain all the
which part ? The appear multiple times ? Yes, you can end up with thing
+options required to enable functionality, partitioned configurations rely onnon-overlapping
+multiple includes to build up a set of non overlapping options to enable
+functionality. Complete groups are simpler to include, but make it moreIf a config fragment includes another one - isn't the end result the same?
+difficult to remove or disable an option (since it can appear multiple
via fragments that include others, but not if you've partitioned them
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.
I would stick with machine or BSP, but not confuse the issue by using
.. I'll try something easier on the head, I was trying to stay out
+supports and is the typical entry point of a build system to theFor whatever reason, that reads as very abstract and is rather difficult
+configuration data of the meta branch.
to parse. I understand it... but _I_ needed to read it several times,
and I know the system fairly well...
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
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 typeIt's still a bit round about. How about:
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.
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 Great. Thanks for doing the write-up Bruce.
but this review was very helpful!
Intel Open Source Technology Center
Yocto Project - Linux Kernel
yocto mailing list