what are the major phases of do_patch() for the kernel?

what are the major phases of do_patch() for the kernel?

[Robert P. J. Day]

  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

... etc, etc.  and at the end of the patch step, i know that i'll have
that untracked top-level "meta" directory, still not sure what will
have been done with it yet.  i guess that's for the next step, which
appears to be "kernel_configme".  but one thing at a time.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what are the major phases of do_patch() for the kernel?

[Bruce Ashfield]

On Thu, Jul 19, 2012 at 5:50 PM, Robert P. J. Day <rpjday@crashcourse.ca> 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.

This is all significantly more detail than anyone needs, and we've moved
these docs from being the first thing that people see ..

Cheers,

Bruce

>
> ... etc, etc.  and at the end of the patch step, i know that i'll have
> that untracked top-level "meta" directory, still not sure what will
> have been done with it yet.  i guess that's for the next step, which
> appears to be "kernel_configme".  but one thing at a time.
>
> 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
> Openembedded-core@lists.openembedded.org
> 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"

Re: what are the major phases of do_patch() for the kernel?

[Robert P. J. Day]

On Thu, 19 Jul 2012, Bruce Ashfield wrote:

> On Thu, Jul 19, 2012 at 5:50 PM, Robert P. J. Day <rpjday@crashcourse.ca> 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.

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what are the major phases of do_patch() for the kernel?

[Bruce Ashfield]

On Sat, Jul 21, 2012 at 6:50 AM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Thu, 19 Jul 2012, Bruce Ashfield wrote:
>
>> On Thu, Jul 19, 2012 at 5:50 PM, Robert P. J. Day <rpjday@crashcourse.ca> 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
> Openembedded-core@lists.openembedded.org
> 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"

Re: what are the major phases of do_patch() for the kernel?

[Robert P. J. Day]

On Sat, 21 Jul 2012, Bruce Ashfield wrote:
... snip ...

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

  points well taken so let me make a much more innocuous suggestion.
perhaps the higher-level routines like createme, updateme, and so on
could have a short comment paragraph or two at the top just
summarizing what they do, nothing more than that.

  i accept that even that higher level is still "under the covers" but
for the fun of it, i'm just following along with each (task) step of
building a yocto kernel, and it would make it *way* easier if i had
just a basic understanding of what each bitbake task was supposed to
accomplish.

  most of those utility scripts already have a "usage" routine -- how
hard would it be to add another few lines of comment as to what the
script is meant to do?

  anyway, i've whined about this sufficiently, so back to the code...

rday

-- 

========================================================================
Robert P. J. Day                                 Ottawa, Ontario, CANADA
                        http://crashcourse.ca

Twitter:                                       http://twitter.com/rpjday
LinkedIn:                               http://ca.linkedin.com/in/rpjday
========================================================================

Re: what are the major phases of do_patch() for the kernel?

[Bruce Ashfield]

On Sat, Jul 21, 2012 at 12:34 PM, Robert P. J. Day
<rpjday@crashcourse.ca> wrote:
> On Sat, 21 Jul 2012, Bruce Ashfield wrote:
> ... snip ...
>
>> 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.
>
>   points well taken so let me make a much more innocuous suggestion.
> perhaps the higher-level routines like createme, updateme, and so on
> could have a short comment paragraph or two at the top just
> summarizing what they do, nothing more than that.

Absolutely. Right in the scripts themselves .. a good suggestion, and
I'll do that, it also saves me providing the information in multiple
places (and I can shout, "read the fine script!" .. not likely, but I can
dream :)

>
>   i accept that even that higher level is still "under the covers" but
> for the fun of it, i'm just following along with each (task) step of
> building a yocto kernel, and it would make it *way* easier if i had
> just a basic understanding of what each bitbake task was supposed to
> accomplish.

Yep. And I agree ... this is good, and no harm. My comments aren't
meant to discourage, just direct to something that is useful for you, me
and anyone else following along :)

>
>   most of those utility scripts already have a "usage" routine -- how
> hard would it be to add another few lines of comment as to what the
> script is meant to do?

Not hard .. I'll whip that up.

>
>   anyway, i've whined about this sufficiently, so back to the code...

That means it is my turn! ;)

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
> Openembedded-core@lists.openembedded.org
> 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"