[OE-core] is "LINUX_VERSION" actually needed for a kernel checkout?

Bruce Ashfield bruce.ashfield at gmail.com
Sun Jul 15 01:04:02 UTC 2012


On Sat, Jul 14, 2012 at 5:55 PM, Khem Raj <raj.khem at 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 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

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




More information about the Openembedded-core mailing list