[meta-xilinx] [PATCH 5/12] linux-xlnx: Add recipe for xilinx-v2017.1 release

[Nathan Rossi]

On 9 May 2017 at 03:35, Manjukumar Harthikote Matha
<manjukumar.harthikote-matha at xilinx.com> wrote:
>
>
>> -----Original Message-----
>> From: meta-xilinx-bounces at yoctoproject.org [mailto:meta-xilinx-
>> bounces at yoctoproject.org] On Behalf Of Nathan Rossi
>> Sent: Sunday, May 07, 2017 7:07 AM
>> To: meta-xilinx at lists.yoctoproject.org
>> Subject: [meta-xilinx] [PATCH 5/12] linux-xlnx: Add recipe for xilinx-v2017.1 release
>>
>> Add a recipe for the xilinx-v2017.1 release, this release is based on kernel version
>> 4.9.
>>
>> Also update the zybo-linux-bd-zynq related patches to apply for this version of the
>> linux-xlnx kernel.
>>
>> Signed-off-by: Nathan Rossi <nathan at nathanrossi.com>
>> ---

... snip ...

>> +
>> diff --git a/recipes-kernel/linux/linux-xlnx_2017.1.bb b/recipes-kernel/linux/linux-
>> xlnx_2017.1.bb
>
> Will send a patch to rename linux-xlnx_2017.1.bb to linux-xlnx_4.9.bb, Yocto standard conventions of indicating kernel versions.

At this time I don't see a reason to change it unless Xilinx changes
how they release their kernels.

The only requirement of a linux recipe from the PV side is that the
version (before the first "-") in the PV matches the KERNEL_VERSION.
There is no convention regarding the name of kernel recipes, apart
from the <pn>_<pv>.bb convention for recipes in general.

Since Xilinx follows a different release versioning policy
comparatively to other vendors/kernels (which tend to essentially
branch for each kernel release and maintain it), the versioning of the
linux-xlnx recipes should match Xilinx's releases.

Note the name of the file does not affect the PV which is set in the
recipe. But the naming convention on the .bb file itself was changed
on purpose, it solves the issue for handling two different releases
(e.g. 2016.3 and 2016.4) which have the same kernel version. The
recipe file name uses the "2016.3" part instead of the full string for
simplicity. This also solves the bbappend issue as well, such that a
bbappend can apply to 2016.3 and not 2016.4.

This same convention has been applied to other recipes, it makes for a
very clear and simple way of allowing multiple releases to be
available for recipes using Xilinx trees/releases and makes it easy to
see which versions are in the layer from the file tree.

Regards,
Nathan