is "LINUX_VERSION" actually needed for a kernel checkout?

is "LINUX_VERSION" actually needed for a kernel checkout?

[Robert P. J. Day]

  pawing my way through the kernel recipe file and checkout code so i
understand it once and for all, and i'm curious about the setting of:

LINUX_VERSION ?= "3.4.4"

in linux-yocto_3.4.bb.

  for my example, i'm testing with straight oe-core and building for
qemuarm, so i can see the following relevant lines from the kernel
recipe file that will affect my kernel checkout:

KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
SRCREV_machine_qemuarm ?= "9aca8fec49787efbe44d0f137f31ee59edd94c49"
SRCREV_meta ?= "a8cf77018b0faa0d29f1483ff4e5a2034dc8edd5"

SRC_URI =
"git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"

LINUX_VERSION ?= "3.4.4"

  as i read the docs (and i could be totally off-base), the KBRANCH
variable identifies the branch i want for my checkout, while the
SRCREV_machine variable identifies the particular commit on that
branch that i want (typically, it's a merge of standard/base into that
branch).  and of course, SRCREV_meta is the state of the meta branch i
want for further configuration.

  but at no time did i need to know the tagged kernel version that my
machine branch was based on, did i?  so for the purposes of what
happened above, i didn't *require* the value of LINUX_VERSION, did i?

  i can see that it will be handy in, say, creating meaningful
directory names for building.  but beyond that, what else is it used
for?  (i haven't got to the meta/ directory processing yet, so i have
no idea whether it's suddenly necessary there.)

rday

-- 

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

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

Re: is "LINUX_VERSION" actually needed for a kernel checkout?

[Bruce Ashfield]

On Sat, Jul 14, 2012 at 3:07 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
>
>   pawing my way through the kernel recipe file and checkout code so i
> understand it once and for all, and i'm curious about the setting of:
>
> LINUX_VERSION ?= "3.4.4"
>
> in linux-yocto_3.4.bb.
>
>   for my example, i'm testing with straight oe-core and building for
> qemuarm, so i can see the following relevant lines from the kernel
> recipe file that will affect my kernel checkout:
>
> KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
> SRCREV_machine_qemuarm ?= "9aca8fec49787efbe44d0f137f31ee59edd94c49"
> SRCREV_meta ?= "a8cf77018b0faa0d29f1483ff4e5a2034dc8edd5"
>
> SRC_URI =
> "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>
> LINUX_VERSION ?= "3.4.4"
>
>   as i read the docs (and i could be totally off-base), the KBRANCH
> variable identifies the branch i want for my checkout, while the
> SRCREV_machine variable identifies the particular commit on that
> branch that i want (typically, it's a merge of standard/base into that
> branch).  and of course, SRCREV_meta is the state of the meta branch i
> want for further configuration.
>
>   but at no time did i need to know the tagged kernel version that my
> machine branch was based on, did i?  so for the purposes of what
> happened above, i didn't *require* the value of LINUX_VERSION, did i?
>
>   i can see that it will be handy in, say, creating meaningful
> directory names for building.  but beyond that, what else is it used
> for?  (i haven't got to the meta/ directory processing yet, so i have
> no idea whether it's suddenly necessary there.)

The kernel itself doesn't care .. but the rest of the system does,
since that is used
for setting PV.

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: is "LINUX_VERSION" actually needed for a kernel checkout?

[Khem Raj]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 7/14/2012 2:26 PM, Bruce Ashfield wrote:
> On Sat, Jul 14, 2012 at 3:07 PM, Robert P. J. Day
> <rpjday@crashcourse.ca> wrote:
>> 
>> pawing my way through the kernel recipe file and checkout code so
>> i understand it once and for all, and i'm curious about the
>> setting of:
>> 
>> LINUX_VERSION ?= "3.4.4"
>> 
>> in linux-yocto_3.4.bb.
>> 
>> for my example, i'm testing with straight oe-core and building
>> for qemuarm, so i can see the following relevant lines from the
>> kernel recipe file that will affect my kernel checkout:
>> 
>> KBRANCH_qemuarm  = "standard/arm-versatile-926ejs" 
>> SRCREV_machine_qemuarm ?=
>> "9aca8fec49787efbe44d0f137f31ee59edd94c49" SRCREV_meta ?=
>> "a8cf77018b0faa0d29f1483ff4e5a2034dc8edd5"
>> 
>> SRC_URI = 
>> "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>
>>
>> 
LINUX_VERSION ?= "3.4.4"
>> 
>> as i read the docs (and i could be totally off-base), the
>> KBRANCH variable identifies the branch i want for my checkout,
>> while the SRCREV_machine variable identifies the particular
>> commit on that branch that i want (typically, it's a merge of
>> standard/base into that branch).  and of course, SRCREV_meta is
>> the state of the meta branch i want for further configuration.
>> 
>> but at no time did i need to know the tagged kernel version that
>> my machine branch was based on, did i?  so for the purposes of
>> what happened above, i didn't *require* the value of
>> LINUX_VERSION, did i?
>> 
>> i can see that it will be handy in, say, creating meaningful 
>> directory names for building.  but beyond that, what else is it
>> used for?  (i haven't got to the meta/ directory processing yet,
>> so i have no idea whether it's suddenly necessary there.)
> 
> The kernel itself doesn't care .. but the rest of the system does, 
> since that is used for setting PV.
> 

I think we only have 1 recipe per release e.g. 3.2, 3.4 and so on so
adding an additional minor is confusing there may be it can be avoided
and when we say 3.4 it means 3.4 release branch of kernel.

unless we plan to have it selectable for users to use 3.4.1 and 3.4.2
it probably loses the significance

> 


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAlAB6rcACgkQuwUzVZGdMxSIxQCfcFYddR+x8FIhH18Ae7lNYAma
nF0AnimKPeYQ/cKVDpr5ckrAIibr4dYa
=qNRw
-----END PGP SIGNATURE-----

Re: is "LINUX_VERSION" actually needed for a kernel checkout?

[Robert P. J. Day]

On Sat, 14 Jul 2012, Khem Raj wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 7/14/2012 2:26 PM, Bruce Ashfield wrote:
> > On Sat, Jul 14, 2012 at 3:07 PM, Robert P. J. Day
> > <rpjday@crashcourse.ca> wrote:
> >>
> >> pawing my way through the kernel recipe file and checkout code so
> >> i understand it once and for all, and i'm curious about the
> >> setting of:
> >>
> >> LINUX_VERSION ?= "3.4.4"
> >>
> >> in linux-yocto_3.4.bb.
> >>
> >> for my example, i'm testing with straight oe-core and building
> >> for qemuarm, so i can see the following relevant lines from the
> >> kernel recipe file that will affect my kernel checkout:
> >>
> >> KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
> >> SRCREV_machine_qemuarm ?=
> >> "9aca8fec49787efbe44d0f137f31ee59edd94c49" SRCREV_meta ?=
> >> "a8cf77018b0faa0d29f1483ff4e5a2034dc8edd5"
> >>
> >> SRC_URI =
> >> "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
> >>
> >>
> >>
> LINUX_VERSION ?= "3.4.4"
> >>
> >> as i read the docs (and i could be totally off-base), the
> >> KBRANCH variable identifies the branch i want for my checkout,
> >> while the SRCREV_machine variable identifies the particular
> >> commit on that branch that i want (typically, it's a merge of
> >> standard/base into that branch).  and of course, SRCREV_meta is
> >> the state of the meta branch i want for further configuration.
> >>
> >> but at no time did i need to know the tagged kernel version that
> >> my machine branch was based on, did i?  so for the purposes of
> >> what happened above, i didn't *require* the value of
> >> LINUX_VERSION, did i?
> >>
> >> i can see that it will be handy in, say, creating meaningful
> >> directory names for building.  but beyond that, what else is it
> >> used for?  (i haven't got to the meta/ directory processing yet,
> >> so i have no idea whether it's suddenly necessary there.)
> >
> > The kernel itself doesn't care .. but the rest of the system does,
> > since that is used for setting PV.
> >
>
> I think we only have 1 recipe per release e.g. 3.2, 3.4 and so on so
> adding an additional minor is confusing there may be it can be avoided
> and when we say 3.4 it means 3.4 release branch of kernel.
>
> unless we plan to have it selectable for users to use 3.4.1 and 3.4.2
> it probably loses the significance

  ok, that nicely summarizes the puzzlement i was having with this.
in the example i was playing with (qemuarm), i could follow the git
commits back in june that represented (for the yocto linux 3.4
kernel),  the steps:

  * official 3.4.4 release
  * merge v3.4.4 into standard/base
  * merge standard/base into standard/arm-versatile-926ejs

and, sure, what we now had was a tree that was "based" on 3.4.4, but i
couldn't figure out why i should care about that level of precision.
as khem points out, what do you need beyond knowing that it's the
current version of the 3.4 kernel supported by yocto?

  on the other hand, i can see the local tarball created by the fetch
of that kernel source tree:

  git2_git.yoctoproject.org.linux-yocto-3.4.git.tar.gz

if you were being consistent, should that also have a "3.4.4" naming
convention?  it seems only fair, no?

rday

-- 

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

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

Re: is "LINUX_VERSION" actually needed for a kernel checkout?

[Bruce Ashfield]

On Sat, Jul 14, 2012 at 6:11 PM, Robert P. J. Day <rpjday@crashcourse.ca> wrote:
> On Sat, 14 Jul 2012, Khem Raj wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 7/14/2012 2:26 PM, Bruce Ashfield wrote:
>> > On Sat, Jul 14, 2012 at 3:07 PM, Robert P. J. Day
>> > <rpjday@crashcourse.ca> wrote:
>> >>
>> >> pawing my way through the kernel recipe file and checkout code so
>> >> i understand it once and for all, and i'm curious about the
>> >> setting of:
>> >>
>> >> LINUX_VERSION ?= "3.4.4"
>> >>
>> >> in linux-yocto_3.4.bb.
>> >>
>> >> for my example, i'm testing with straight oe-core and building
>> >> for qemuarm, so i can see the following relevant lines from the
>> >> kernel recipe file that will affect my kernel checkout:
>> >>
>> >> KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
>> >> SRCREV_machine_qemuarm ?=
>> >> "9aca8fec49787efbe44d0f137f31ee59edd94c49" SRCREV_meta ?=
>> >> "a8cf77018b0faa0d29f1483ff4e5a2034dc8edd5"
>> >>
>> >> SRC_URI =
>> >> "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>> >>
>> >>
>> >>
>> LINUX_VERSION ?= "3.4.4"
>> >>
>> >> as i read the docs (and i could be totally off-base), the
>> >> KBRANCH variable identifies the branch i want for my checkout,
>> >> while the SRCREV_machine variable identifies the particular
>> >> commit on that branch that i want (typically, it's a merge of
>> >> standard/base into that branch).  and of course, SRCREV_meta is
>> >> the state of the meta branch i want for further configuration.
>> >>
>> >> but at no time did i need to know the tagged kernel version that
>> >> my machine branch was based on, did i?  so for the purposes of
>> >> what happened above, i didn't *require* the value of
>> >> LINUX_VERSION, did i?
>> >>
>> >> i can see that it will be handy in, say, creating meaningful
>> >> directory names for building.  but beyond that, what else is it
>> >> used for?  (i haven't got to the meta/ directory processing yet,
>> >> so i have no idea whether it's suddenly necessary there.)
>> >
>> > The kernel itself doesn't care .. but the rest of the system does,
>> > since that is used for setting PV.
>> >
>>
>> I think we only have 1 recipe per release e.g. 3.2, 3.4 and so on so
>> adding an additional minor is confusing there may be it can be avoided
>> and when we say 3.4 it means 3.4 release branch of kernel.
>>
>> unless we plan to have it selectable for users to use 3.4.1 and 3.4.2
>> it probably loses the significance
>
>   ok, that nicely summarizes the puzzlement i was having with this.
> in the example i was playing with (qemuarm), i could follow the git
> commits back in june that represented (for the yocto linux 3.4
> kernel),  the steps:
>
>   * official 3.4.4 release
>   * merge v3.4.4 into standard/base
>   * merge standard/base into standard/arm-versatile-926ejs
>
> and, sure, what we now had was a tree that was "based" on 3.4.4, but i
> couldn't figure out why i should care about that level of precision.
> as khem points out, what do you need beyond knowing that it's the
> current version of the 3.4 kernel supported by yocto?

There's plenty of people who want to know right down to the -stable release.
(Wind River does, as do a lot of people stuck debugging nasty regressions).
Having that information available at a glance, in a clearly named variable
(that can be used to trigger temporary work arounds) versus hunting it out
of the git branches or checking the abiversion file .. just make sense.

>
>   on the other hand, i can see the local tarball created by the fetch
> of that kernel source tree:
>
>   git2_git.yoctoproject.org.linux-yocto-3.4.git.tar.gz
>
> if you were being consistent, should that also have a "3.4.4" naming
> convention?  it seems only fair, no?

You are talking about the git tree itself .. no, we can't have that level of
precision. 3.4.4 will shortly become 3.4.5, etc. If there's a fetcher flag that
would let it be named differently on disk rather than using the SRC_URI
repo name .. that's one option, but I wouldn't jump on using that either, since
it is just yet another magic argument and behaviour :)

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: is "LINUX_VERSION" actually needed for a kernel checkout?

[Bruce Ashfield]

On Sat, Jul 14, 2012 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 7/14/2012 2:26 PM, Bruce Ashfield wrote:
>> On Sat, Jul 14, 2012 at 3:07 PM, Robert P. J. Day
>> <rpjday@crashcourse.ca> wrote:
>>>
>>> pawing my way through the kernel recipe file and checkout code so
>>> i understand it once and for all, and i'm curious about the
>>> setting of:
>>>
>>> LINUX_VERSION ?= "3.4.4"
>>>
>>> in linux-yocto_3.4.bb.
>>>
>>> for my example, i'm testing with straight oe-core and building
>>> for qemuarm, so i can see the following relevant lines from the
>>> kernel recipe file that will affect my kernel checkout:
>>>
>>> KBRANCH_qemuarm  = "standard/arm-versatile-926ejs"
>>> SRCREV_machine_qemuarm ?=
>>> "9aca8fec49787efbe44d0f137f31ee59edd94c49" SRCREV_meta ?=
>>> "a8cf77018b0faa0d29f1483ff4e5a2034dc8edd5"
>>>
>>> SRC_URI =
>>> "git://git.yoctoproject.org/linux-yocto-3.4.git;protocol=git;nocheckout=1;branch=${KBRANCH},meta;name=machine,meta"
>>>
>>>
>>>
> LINUX_VERSION ?= "3.4.4"
>>>
>>> as i read the docs (and i could be totally off-base), the
>>> KBRANCH variable identifies the branch i want for my checkout,
>>> while the SRCREV_machine variable identifies the particular
>>> commit on that branch that i want (typically, it's a merge of
>>> standard/base into that branch).  and of course, SRCREV_meta is
>>> the state of the meta branch i want for further configuration.
>>>
>>> but at no time did i need to know the tagged kernel version that
>>> my machine branch was based on, did i?  so for the purposes of
>>> what happened above, i didn't *require* the value of
>>> LINUX_VERSION, did i?
>>>
>>> i can see that it will be handy in, say, creating meaningful
>>> directory names for building.  but beyond that, what else is it
>>> used for?  (i haven't got to the meta/ directory processing yet,
>>> so i have no idea whether it's suddenly necessary there.)
>>
>> The kernel itself doesn't care .. but the rest of the system does,
>> since that is used for setting PV.
>>
>
> I think we only have 1 recipe per release e.g. 3.2, 3.4 and so on so
> adding an additional minor is confusing there may be it can be avoided
> and when we say 3.4 it means 3.4 release branch of kernel.
>
> unless we plan to have it selectable for users to use 3.4.1 and 3.4.2
> it probably loses the significance

selectable no .. but useful none the less. It's clear information (that does no
harm), that has it's users and use cases, so I have no plans to abandon it.

Cheers,

Bruce

>
>>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iEYEARECAAYFAlAB6rcACgkQuwUzVZGdMxSIxQCfcFYddR+x8FIhH18Ae7lNYAma
> nF0AnimKPeYQ/cKVDpr5ckrAIibr4dYa
> =qNRw
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> 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"