[meta-freescale] [PATCH 01/14] linux-libc-headers: Use linux-libc-headers v4.9 for L4.9.123-2.3.0_8mm_ga
Max Krummenacher
max.oss.09 at gmail.com
Mon Oct 1 02:26:55 PDT 2018
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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/meta-freescale/attachments/20181001/ff442590/attachment.html>
More information about the meta-freescale
mailing list