-----Original Message-----
From: meta-freescale@... <meta-freescale@...> On Behalf Of Otavio Salvador via lists.yoctoproject.org
Sent: Friday, April 10, 2020 11:52 AM
To: Gary Bisson <gary.bisson@...>
Cc: Carlos Rafael Giani <crg7475@...>; meta-freescale <meta-freescale@...>; Chris Dimich <chris.dimich@...>
Subject: Re: [meta-freescale] linux-imx-headers and ioctl mismatches

On Fri, Apr 10, 2020 at 11:46 AM Gary Bisson <gary.bisson@...> wrote:

On Fri, Apr 10, 2020 at 11:22:45AM -0300, Otavio Salvador wrote:

On Fri, Apr 10, 2020 at 11:20 AM Carlos Rafael Giani
<crg7475@...> wrote:

Hm I thought there was some sort of imx-kernel base class.
Apparently there isn't. If there were, it could then be merged
with the linux-imx-headers recipe, and perhaps create something like a -dev package.

But then again, a -dev package from a kernel recipe ...? Kind of weird.

The problem is that you cannot mix packages / apps with different
versions of this. This ends being part of the binary ABI.

I understand it's a tricky topic as some packages won't build if the
kernel headers are not aligned. But I'm not sure it is better to have
packages building but having runtime issues because of mismatch...

Since our kernel is also used on other OSes we will not update its
headers. It also feels wrong to do so.

Add a patch to the layer for it.

Otavio, do you expect all the vendors to have their kernel matching
exactly the linux-imx-headers version?
Because looking at meta-freescale-3rdparty master branch [1], some
kernels are still based on 3.14...

and it is vendors consideration for their users. If they don't care, who should care? We are starting removing broken boards and vendors should pay attention to users.

There are two routes here:

- use mainline BSP
- use NXP BSP

for NXP BSP it comes with the need to keep upgrading it.

I personnaly think that the headers should be installed from the
kernel being built, then it's up to the vendor to check the
compatibility but at least that would fix the issue Carlos is seeing.

This does not help; those headers should not exists in first case but as we do, a common base need to be used for all distro. Their symbols goes to other libraries and apps so it cannot change between machines.

FYI, our next kernel release will be 5.4.3_1.0.0 as it is out since
last week. So if master stays with 4.19 we'll still have a mismatch I guess.

Will be going to 5.4 soon and people can help, patches welcome.

--
Otavio Salvador O.S. Systems
http://www.ossystems.com.br http://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854 Mobile: +1 (347) 903-9750