meta-freescale@lists.yoctoproject.org

Re: linux-imx-headers and ioctl mismatches

Otavio Salvador

#24295

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

Re: linux-imx-headers and ioctl mismatches

Otavio Salvador

#24294

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.

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

Re: linux-imx-headers and ioctl mismatches

Carlos Rafael Giani

#24293

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.

Show quoted text

On 10.04.20 16:12, Otavio Salvador wrote:
On Fri, Apr 10, 2020 at 7:19 AM Carlos Rafael Giani <crg7475@...> wrote:
...
Just mentioning this here to discuss ideas. Perhaps it would make sense
to create a virtual/imx-headers package, or place the git repo URL as a
configurable variable?This is not an easy problem. The issue is kinda similar of Linux ABI
and we can't use two different versions on same binary feed so we'd
need to mark it all as MACHINE_ARCH.

The easiest solution I can think of is do a backport of this change to
linux-boundary or they bump their kernel version.

Re: linux-imx-headers and ioctl mismatches

Otavio Salvador

#24292

On Fri, Apr 10, 2020 at 7:19 AM Carlos Rafael Giani <crg7475@...> wrote:
...
Just mentioning this here to discuss ideas. Perhaps it would make sense
to create a virtual/imx-headers package, or place the git repo URL as a
configurable variable?This is not an easy problem. The issue is kinda similar of Linux ABI
and we can't use two different versions on same binary feed so we'd
need to mark it all as MACHINE_ARCH.

The easiest solution I can think of is do a backport of this change to
linux-boundary or they bump their kernel version.


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

linux-imx-headers and ioctl mismatches

Carlos Rafael Giani

#24291

The linux-imx-headers recipe gathers certain headers from the kernel source so that other recipes which do access these headers don't have to mark the entire kernel as a dependency.

However, if a platform doesn't actually use linux-imx as its kernel, or at least uses a kernel release version that differs from that of linux-imx, ioctl mismatches can occur.

Current example: linux-imx is at version 4.19 , while linux-boundary is at 4.14. The DMA_BUF_IOCTL_PHYS ioctl is defined in the uapi/dma-buf.h header in 4.14 as:

  #define DMA_BUF_IOCTL_PHYS      _IOW(DMA_BUF_BASE, 1, struct dma_buf_phys)

but in 4.19 as:

  #define DMA_BUF_IOCTL_PHYS      _IOW(DMA_BUF_BASE, 10, struct dma_buf_phys)

This leads to Boundary Devices platforms that can't handle this ioctl properly because of the definition mismatch.

Just mentioning this here to discuss ideas. Perhaps it would make sense to create a virtual/imx-headers package, or place the git repo URL as a configurable variable?