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.h...@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@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto _______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto