gst-fsl-plugins: requires kernel headers <= 3.10 (branch yem/quickies)

PATCH New Yann E. MORIN 4 participants 10 messages Jul 25, 2014 – Jul 27, 2014

lore

Share & tools

lore

Yann E. MORIN

author

2014-07-25 21:28 UTC #0 lore raw

cover gst-fsl-plugins: requires kernel headers <= 3.10 (branch yem/quickies)

Hello All!

As reported by Gary, gst-fsl-plugins use part of the v4l2 API that was removed in linux 3.11, so it should not be made available for toolchains with kernel headers >= 3.11, but only for headers <= 3.10.

The first patch enhances the manual, explicitly stating that the _AT_LEAST_X_Y dependencies can be used both ways, either to require at least a specific version, or to require@most a specific version. or even both (e.g.: 3.2 <= version <= 3.11 .)

The second patch adds the headers version dependency to gst-fsl-plugins.

Regards,
Yann E. MORIN.

The following changes since commit 5af28fe6a10976eee7d9e9006baa90543d6dd025:

pkg-autotools: add support for <pkg>_AUTORECONF_ENV (2014-07-23 23:49:10 +0200)

are available in the git repository at:

git://gitorious.org/buildroot/buildroot.git yem/quickies

for you to fetch changes up to 09b3dee632b2855fe6517fbdbde2ac9d8a98dbbc:

package/gst-fsl-plugins: not available for kernel headers >= 3.11 (2014-07-25 23:20:27 +0200)

----------------------------------------------------------------
Yann E. MORIN (2):
docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y package/gst-fsl-plugins: not available for kernel headers >= 3.11

 docs/manual/adding-packages-directory.txt   | 4 ++--
 package/gstreamer/gst-fsl-plugins/Config.in | 5 +++--
 2 files changed, 5 insertions(+), 4 deletions(-)

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Yann E. MORIN

author

2014-07-25 21:28 UTC #1 lore raw

PATCH 1/2 docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y

The BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y symbols can be used to denote the lowest required kernel headers version, but also the highest supported version. Document that.

Use the ... construct instead of +...+ used eveywhere else, otherwise asciidoc would render +<=+ to the ? arrow, while ... does no rendering at all.

Signed-off-by "Yann E. MORIN" <[email protected]>

---
 docs/manual/adding-packages-directory.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

docs/manual/adding-packages-directory.txt +2 -2

index c2f0a1a..93e6a3e 100644
@@ -222,8 +222,8 @@ use in the comment.
 * Kernel headers
 ** Dependency symbol: +BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y+, (replace
    +X_Y+ with the proper version, see +toolchain/toolchain-common.in+)
-** Comment string: +headers >= X.Y+ (replace +X.Y+ with the
-   proper version)
+** Comment string: +headers >= X.Y+ and/or `headers <= X.Y` (replace
+   +X.Y+ with the proper version)
 
 * C library
 ** Dependency symbol: +BR2_TOOLCHAIN_USES_GLIBC+,

Signature · 1 line

1.9.1

Thomas De Schampheleire

2014-07-26 18:25 UTC #2 lore raw

PATCH 1/2 docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y

Quoted 18 lines · Yann E. MORIN

The BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y symbols can be used to denote the lowest required kernel headers version, but also the highest supported version. Document that.
Use the ... construct instead of +...+ used eveywhere else, otherwise asciidoc would render +<=+ to the ? arrow, while ... does no rendering at all.
Signed-off-by "Yann E. MORIN" <[email protected]>
---
 docs/manual/adding-packages-directory.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
docs/manual/adding-packages-directory.txt +0 -0
index c2f0a1a..93e6a3e 100644

docs/manual/adding-packages-directory.txt use in the comment. · line 229

Quoted 10 lines

docs/manual/adding-packages-directory.txt +2 -2

@@ -222,8 +222,8 @@ use in the comment.
 * Kernel headers
 ** Dependency symbol: +BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y+, (replace
    +X_Y+ with the proper version, see +toolchain/toolchain-common.in+)
-** Comment string: +headers >= X.Y+ (replace +X.Y+ with the
-   proper version)
+** Comment string: +headers >= X.Y+ and/or `headers <= X.Y` (replace
+   +X.Y+ with the proper version)
 
 * C library
 ** Dependency symbol: +BR2_TOOLCHAIN_USES_GLIBC+,

Acked-by Thomas De Schampheleire <[email protected]>

Thomas Petazzoni

2014-07-27 12:34 UTC #3 lore raw

PATCH 1/2 docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y

In reply to Yann E. MORIN

Dear Yann E. MORIN,

Quoted 3 lines · Yann E. MORIN

The BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y symbols can be used to denote the lowest required kernel headers version, but also the highest supported version. Document that.

I'm honestly really unsure about this. Kernel headers expose the kernel to userspace API, and this API is supposed to be backward compatible. Therefore, I don't see why we should document the idea of expressing on dependency on a highest kernel header version.

The v4l2 example we had on freescale seems like an API that shouldn't have been part of the kernel to userspace API, and therefore shouldn't be used by userspace libraries/applications.

Therefore, I'm tempted to say no to this patch, but I'm interested to be convince otherwise :)

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Yann E. MORIN

author

2014-07-27 12:49 UTC #4 lore raw

PATCH 1/2 docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y

Thomas, All,

On 2014-07-27 14:34 +0200, Thomas Petazzoni spake thusly:

Quoted 10 lines · Yann E. MORIN

Quoted 3 lines
The BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y symbols can be used to denote the lowest required kernel headers version, but also the highest supported version. Document that.
I'm honestly really unsure about this. Kernel headers expose the kernel to userspace API, and this API is supposed to be backward compatible. Therefore, I don't see why we should document the idea of expressing on dependency on a highest kernel header version.

Quoted 6 lines

The v4l2 example we had on freescale seems like an API that shouldn't have been part of the kernel to userspace API, and therefore shouldn't be used by userspace libraries/applications.
Therefore, I'm tempted to say no to this patch, but I'm interested to be convince otherwise :)

Well, APIs can get deprecated over time, and eventually removed. For example, the status of interfaces is described in Documentation/ABI in your favourite kernel source tree.

So, yes, I still think this patch is valid.

Regards,
Yann E. MORIN.

Signature · 6 lines

.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Thomas Petazzoni

2014-07-27 13:04 UTC #5 lore raw

PATCH 1/2 docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y

Dear Yann E. MORIN,

Quoted 6 lines · Yann E. MORIN

Quoted 2 lines
Therefore, I'm tempted to say no to this patch, but I'm interested to be convince otherwise :)
Well, APIs can get deprecated over time, and eventually removed. For example, the status of interfaces is described in Documentation/ABI in your favourite kernel source tree.

Yeah, well, that's true. Even though that tends to happen very rarely and generally for very rarely used interfaces.

Quoted 1 line

So, yes, I still think this patch is valid.

Ok, fair enough :)

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Thomas Petazzoni

Applied

2014-07-27 13:08 UTC #6 lore raw

PATCH 1/2 docs/manual: enhance doc for BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y

In reply to Yann E. MORIN

Dear Yann E. MORIN,

Quoted 4 lines · Yann E. MORIN

The BR2_TOOLCHAIN_HEADERS_AT_LEAST_X_Y symbols can be used to denote the lowest required kernel headers version, but also the highest supported version. Document that.

Quoted 8 lines

Use the ... construct instead of +...+ used eveywhere else, otherwise asciidoc would render +<=+ to the ? arrow, while ... does no rendering at all.
Signed-off-by "Yann E. MORIN" <[email protected]>
---
 docs/manual/adding-packages-directory.txt | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

Applied, thanks.

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Yann E. MORIN

author

2014-07-25 21:28 UTC #7 lore raw

PATCH 2/2 package/gst-fsl-plugins: not available for kernel headers >= 3.11

In reply to Yann E. MORIN

gst-fsl-plugins the v4l2 API, such as 'struct v4l2_dbg_chip_ident', that was removed in 3.11.

So, limit this package to toolchains with kernel headers <= 3.10.

Reported-by Gary Bisson <[email protected]>

Signed-off-by "Yann E. MORIN" <[email protected]>

Cc Gary Bisson <[email protected]>

---
 package/gstreamer/gst-fsl-plugins/Config.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

package/gstreamer/gst-fsl-plugins/Config.in +3 -2

index 309e745..e1daddb 100644
@@ -1,15 +1,16 @@
 comment "gst-fsl-plugins needs an imx-specific Linux kernel to be built"
 	depends on BR2_arm && !BR2_LINUX_KERNEL
 
-comment "gst-fsl-plugins needs an (e)glibc toolchain"
+comment "gst-fsl-plugins needs an (e)glibc toolchain w/ headers <= 3.10"
 	depends on BR2_arm
-	depends on !BR2_TOOLCHAIN_USES_GLIBC
+	depends on !BR2_TOOLCHAIN_USES_GLIBC || BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11
 
 config BR2_PACKAGE_GST_FSL_PLUGINS
 	bool "gst-fsl-plugins"
 	depends on BR2_LINUX_KERNEL
 	depends on BR2_arm # Only relevant for i.MX
 	depends on BR2_TOOLCHAIN_USES_GLIBC # libfslcodec
+	depends on !BR2_TOOLCHAIN_HEADERS_AT_LEAST_3_11 # Uses v4l2 API changed in 3.11
 	select BR2_PACKAGE_GST_PLUGINS_BASE
 	select BR2_PACKAGE_LIBFSLVPUWRAP
 	select BR2_PACKAGE_IMX_LIB

Signature · 1 line

1.9.1

Thomas Petazzoni

2014-07-25 22:32 UTC #8 lore raw

cover gst-fsl-plugins: requires kernel headers <= 3.10 (branch yem/quickies)

In reply to Yann E. MORIN

Dear Yann E. MORIN,

Quoted 3 lines · Yann E. MORIN

As reported by Gary, gst-fsl-plugins use part of the v4l2 API that was removed in linux 3.11, so it should not be made available for toolchains with kernel headers >= 3.11, but only for headers <= 3.10.

That's kind of odd. Isn't the kernel to userspace API supposed to remain backward compatible? Isn't this rather a story of custom v4l2 APIs added by Freescale but never mainlined?

Thomas

Signature · 3 lines

Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

Gary Bisson

2014-07-25 23:21 UTC #9 lore raw

cover gst-fsl-plugins: requires kernel headers <= 3.10 (branch yem/quickies)

Thomas, Yann, all,

Quoted 4 lines · Thomas Petazzoni

Dear Yann E. MORIN,
On Fri, 25 Jul 2014 23:28:11 +0200, Yann E. MORIN wrote:

Quoted 9 lines

Quoted 3 lines
As reported by Gary, gst-fsl-plugins use part of the v4l2 API that was removed in linux 3.11, so it should not be made available for toolchains with kernel headers >= 3.11, but only for headers <= 3.10.
That's kind of odd. Isn't the kernel to userspace API supposed to remain backward compatible? Isn't this rather a story of custom v4l2 APIs added by Freescale but never mainlined?

I confirm the structure disappeared in between kernel 3.10 and 3.11 (see include/uapi/linux/videodev2.h). Commit b71c9980 explains that this structure
and the associated ioctl were deprecated and therefore removed. In other words Freescale shouldn't use that structure. I'll offer another patch
that replaces chip_ident by chip_info.

Thanks,
Gary

Quoted 6 lines

Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20140725/08472c55/attachment.html>