[meta-freescale] [PATCH 01/14] linux-libc-headers: Use linux-libc-headers v4.9 for L4.9.123-2.3.0_8mm_ga
Gary Bisson
gary.bisson at boundarydevices.com
Mon Oct 1 03:24:30 PDT 2018
Hi,
+1, I agree with Max that this seems like a bad idea.
That is for this reason that we avoided to copy ion.h around, having the
packages that need it to look directly to its default location.
Can't we do the same for dma-buf.h?
Regards,
Gary Bisson
Boundary Devices, LLC
www.boundarydevices.com <http://www.BoundaryDevices.com>
On Mon, Oct 1, 2018 at 11:28 AM Max Krummenacher <max.oss.09 at gmail.com>
wrote:
> Hi
>
> Why exactly is this needed?
> Forking usually is not the solution, it is the beginning of the painfull
> process of merging again...
> So I have strong feelings against this change.
>
> By changing linux-libc-headers you also change libc. So nearly everything
> built becomes now machine specific.
>
> Regards
> Max
>
> Note that Install-dma-buf-h.patch is not part of the SRC_URI and thus not
> applied. Mainline fixed this with this commit:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?h=linux-4.14.y&id=2220fc1ab363e6fab1f321430d69be17a8b92bd7
> Later they made the explicit list of uapi headers even unneeded:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=linux-4.14.y&id=fcc8487d477a3452a1d0ccbdd4c5e0e1e3cb8bed
>
>
>
> Am So., 30. Sep. 2018 um 10:55 Uhr schrieb Yuqing Zhu <carol.zhu at nxp.com>:
>
>> Hold linux-libc-headers v4.9 in meta-freescale layer,
>> which matches the current linux-imx version in L4.9.123-2.3.0_8mm_ga.
>>
>> Signed-off-by: Yuqing Zhu <carol.zhu at nxp.com>
>> ---
>> .../files/Install-dma-buf-h.patch | 12 +++
>> .../linux-libc-headers/linux-libc-headers.inc | 91
>> ++++++++++++++++++++++
>> .../linux-libc-headers/linux-libc-headers_4.9.bb | 11 +++
>> 3 files changed, 114 insertions(+)
>> create mode 100644
>> recipes-kernel/linux-libc-headers/files/Install-dma-buf-h.patch
>> create mode 100644
>> recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> create mode 100644 recipes-kernel/linux-libc-headers/
>> linux-libc-headers_4.9.bb
>>
>> diff --git
>> a/recipes-kernel/linux-libc-headers/files/Install-dma-buf-h.patch
>> b/recipes-kernel/linux-libc-headers/files/Install-dma-buf-h.patch
>> new file mode 100644
>> index 0000000..285ccc4
>> --- /dev/null
>> +++ b/recipes-kernel/linux-libc-headers/files/Install-dma-buf-h.patch
>> @@ -0,0 +1,12 @@
>> +Index: git/include/uapi/linux/Kbuild
>> +===================================================================
>> +--- git.orig/include/uapi/linux/Kbuild 2017-07-18 10:58:56.217022277
>> -0500
>> ++++ git/include/uapi/linux/Kbuild 2017-07-18 16:04:47.096019372
>> -0500
>> +@@ -104,6 +104,7 @@
>> + header-y += dlm.h
>> + header-y += dlm_netlink.h
>> + header-y += dlm_plock.h
>> ++header-y += dma-buf.h
>> + header-y += dm-ioctl.h
>> + header-y += dm-log-userspace.h
>> + header-y += dn.h
>> diff --git a/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> b/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> new file mode 100644
>> index 0000000..1657df6
>> --- /dev/null
>> +++ b/recipes-kernel/linux-libc-headers/linux-libc-headers.inc
>> @@ -0,0 +1,91 @@
>> +SUMMARY = "Sanitized set of kernel headers for the C library's use"
>> +SECTION = "devel"
>> +LICENSE = "GPLv2"
>> +
>> +#########################################################################
>> +#### PLEASE READ
>> +#########################################################################
>> +#
>> +# You're probably looking here thinking you need to create some new copy
>> +# of linux-libc-headers since you have your own custom kernel. To put
>> +# this simply, you DO NOT.
>> +#
>> +# Why? These headers are used to build the libc. If you customise the
>> +# headers you are customising the libc and the libc becomes machine
>> +# specific. Most people do not add custom libc extensions to the kernel
>> +# and have a machine specific libc.
>> +#
>> +# But you have some kernel headers you need for some driver? That is fine
>> +# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
>> +# This will make the package using them machine specific but this is much
>> +# better than having a machine specific C library. This does mean your
>> +# recipe needs a
>> +# do_configure[depends] += "virtual/kernel:do_shared_workdir"
>> +# but again, that is fine and makes total sense.
>> +#
>> +# There can also be a case where your kernel extremely old and you want
>> +# an older libc ABI for that old kernel. The headers installed by this
>> +# recipe should still be a standard mainline kernel, not your own custom
>> +# one.
>> +#
>> +# -- RP
>> +
>> +LIC_FILES_CHKSUM = "file://COPYING;md5=d7810fab7487fb0aad327b76f1be7cd7"
>> +
>> +python __anonymous () {
>> + major = d.getVar("PV").split('.')[0]
>> + if major == "3":
>> + d.setVar("HEADER_FETCH_VER", "3.0")
>> + elif major == "4":
>> + d.setVar("HEADER_FETCH_VER", "4.x")
>> + else:
>> + d.setVar("HEADER_FETCH_VER", "2.6")
>> +}
>> +
>> +inherit kernel-arch pkgconfig multilib_header
>> +
>> +KORG_ARCHIVE_COMPRESSION ?= "xz"
>> +
>> +SRC_URI =
>> "${KERNELORG_MIRROR}/linux/kernel/v${HEADER_FETCH_VER}/linux-${PV}.tar.${KORG_ARCHIVE_COMPRESSION}"
>> +UPSTREAM_CHECK_URI = "https://www.kernel.org/"
>> +
>> +S = "${WORKDIR}/linux-${PV}"
>> +
>> +EXTRA_OEMAKE = " HOSTCC="${BUILD_CC}" HOSTCPP="${BUILD_CPP}""
>> +
>> +do_configure() {
>> + oe_runmake allnoconfig
>> +}
>> +
>> +do_compile () {
>> +}
>> +
>> +do_install() {
>> + oe_runmake headers_install INSTALL_HDR_PATH=${D}${exec_prefix}
>> + # Kernel should not be exporting this header
>> + rm -f ${D}${exec_prefix}/include/scsi/scsi.h
>> +
>> + # The ..install.cmd conflicts between various configure runs
>> + find ${D}${includedir} -name ..install.cmd | xargs rm -f
>> +}
>> +
>> +do_install_append_aarch64 () {
>> + do_install_armmultilib
>> +}
>> +
>> +do_install_append_arm () {
>> + do_install_armmultilib
>> +}
>> +
>> +do_install_armmultilib () {
>> + oe_multilib_header asm/auxvec.h asm/bitsperlong.h asm/byteorder.h
>> asm/fcntl.h asm/hwcap.h asm/ioctls.h asm/kvm.h asm/mman.h asm/param.h
>> asm/perf_regs.h
>> + oe_multilib_header asm/posix_types.h asm/ptrace.h asm/setup.h
>> asm/sigcontext.h asm/siginfo.h asm/signal.h asm/stat.h asm/statfs.h
>> asm/swab.h asm/types.h asm/unistd.h
>> +}
>> +
>> +BBCLASSEXTEND = "nativesdk"
>> +
>> +RDEPENDS_${PN}-dev = ""
>> +RRECOMMENDS_${PN}-dbg = "${PN}-dev (= ${EXTENDPKGV})"
>> +
>> +INHIBIT_DEFAULT_DEPS = "1"
>> +DEPENDS += "unifdef-native"
>> diff --git a/recipes-kernel/linux-libc-headers/linux-libc-headers_4.9.bb
>> b/recipes-kernel/linux-libc-headers/linux-libc-headers_4.9.bb
>> new file mode 100644
>> index 0000000..d02c355
>> --- /dev/null
>> +++ b/recipes-kernel/linux-libc-headers/linux-libc-headers_4.9.bb
>> @@ -0,0 +1,11 @@
>> +require linux-libc-headers.inc
>> +
>> +SRC_URI_append_libc-musl = "\
>> + file://0001-libc-compat.h-fix-some-issues-arising-from-in6.h.patch \
>> +
>> file://0002-libc-compat.h-prevent-redefinition-of-struct-ethhdr.patch \
>> + file://0003-remove-inclusion-of-sysinfo.h-in-kernel.h.patch \
>> +
>> file://0001-libc-compat.h-musl-_does_-define-IFF_LOWER_UP-DORMAN.patch \
>> + "
>> +
>> +SRC_URI[md5sum] = "0a68ef3615c64bd5ee54a3320e46667d"
>> +SRC_URI[sha256sum] =
>> "029098dcffab74875e086ae970e3828456838da6e0ba22ce3f64ef764f3d7f1a"
>> --
>> 1.9.1
>>
>> --
>> _______________________________________________
>> meta-freescale mailing list
>> meta-freescale at yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/meta-freescale
>>
> --
> _______________________________________________
> meta-freescale mailing list
> meta-freescale at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/meta-freescale
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20181001/4cf265d3/attachment.html>
More information about the meta-freescale
mailing list