On Sat, Jul 21, 2012 at 6:50 AM, Robert P. J. Day <[email protected]> wrote: > On Thu, 19 Jul 2012, Bruce Ashfield wrote: > >> On Thu, Jul 19, 2012 at 5:50 PM, Robert P. J. Day <[email protected]> >> wrote: >> > >> > short version: what happens during each major processing step of the >> > do_patch function for the kernel? >> > >> > longer version: i'm stepping through what happens when i do a >> > "bitbake linux-yocto", and documenting what happens at each step -- >> > currently looking at do_patch(). >> > >> > after having run the previous validate_branches target, what i >> > appear to have is the source directory containing the kernel source >> > with the (for me) standard/arm-versatile-926ejs branch checked out, >> > and no top-level "meta" directory. so far, so good. >> > >> > now, i'm building core-image-minimal for qemuarm, so i'm being as >> > unexciting and non-exotic as possible -- not selecting any special >> > parameters or corner cases or anything. >> > >> > so as i peruse do_patch() in kernel-yocto.bbclass, i'm following >> > along to functions like createme and updateme and patchme, and with >> > createme, further into decheckpoint and check_defconfig and ... you >> > get the idea. and i'm kind of getting lost in the weeds of details. >> > >> > given that i'm building an absolutely stock target with a supported >> > machine, all i really need for the moment is a very high-level >> > explanation of what each of those main routines does. >> > >> > so if my initial understanding is correct (that before i start >> > do_patch), i have the stock yocto kernel checked out to the >> > appropriate machine branch and nothing else), what does each >> > subsequent step accomplish? >> > >> > don't need horrific detail, just one line or less as to what's >> > accomplished by each step like: >> > >> > * createme >> > * decheckpoint >> > * checkdefconfig >> > * check_branch >> > * metaize >> > * updateme >> >> Most of this is already covered in the kernel architecture manual >> that you can find on the yocto pages .. I'd suggest starting there. > > actually, i *was* going through your kernel manual and the major > thing that was causing me grief was a lack of precise terminology. > when you're reading chapter 3, there are numerous references to the > "kernel tree", but i think it would be massively useful to distinguish > between the variations of tree here. > > one could start by mentioning the pristine kernel.org tree that's > used as a starting point. then there's the tree one checks out of > git.yoctoproject.org, which contains (among other things) a "meta" > branch which is then added to that tree and its content applied. from > what i can read in the kern-tools utilities, that might be called the > "metaize"d tree. after which the configuration is done, and so on. > > terminology matters. all i'm after is, if i'm describing this > process to a class, i want to use terminology that matches what's in > the manuals.
Sure ... but I'll point out that you are going into architectural details that are under the covers, and that are written from the point of view of a kernel tree maintainer using the tools, they are not written from the point of view of the casual observer. The moving parts of the tools that can be tweaked, are already brought out out to the recipes (I'll point out again that the bitbake recipes you see are but one binding). So yes, another variation of the document might be useful, but I've (we've), moved these details out from "in front" and instead have focussed on the use cases .. from someone creating a new BSP, or adding a configuration fragment to their build .. i.e. it looks and works just like any other package in the system from the point of view of user manipulations, with the extra functionality available if someone has used them, and finds that their use case doesn't fit the mold (i.e. how many people go an need to modify bitbake when using oe-core? it took me 2 years to need to do that). What is the goal of a class that you'd be trying to do around this ? That makes all the difference in what I'd suggest for options and changes. Cheers, Bruce > > rday > > -- > > ======================================================================== > Robert P. J. Day Ottawa, Ontario, CANADA > http://crashcourse.ca > > Twitter: http://twitter.com/rpjday > LinkedIn: http://ca.linkedin.com/in/rpjday > ======================================================================== > > _______________________________________________ > Openembedded-core mailing list > [email protected] > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core -- "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end" _______________________________________________ Openembedded-core mailing list [email protected] http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
