[OE-core] 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 at 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 at 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 at 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"