| Message ID | 811e1f5fe52c239010c412ce9f22b307d115cfcf.1453314776.git.yann.morin.1998@free.fr |
|---|---|
| State | Superseded |
| Headers | show |
Dear Yann E. MORIN, On Wed, 20 Jan 2016 19:34:29 +0100, Yann E. MORIN wrote: > Now that we can say that the linux headers version should match that of > the kernel to be built, we inverse the logic in our defconfigs, as it is > more sensible that way. > > And also because we'll get rid of the former, converse kernel-same-as-headers > option. > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> In this commit, you are changing the defconfigs that use BR2_LINUX_KERNEL_SAME_AS_HEADERS. But I am wondering if we shouldn't simply change *all* defconfigs to use this new feature. Essentially all defconfigs have to worry about selecting a kernel headers version that matches the kernel version they use. We could switch them all to use your new mechanism, no? Of course, this can be done as a separate effort, this is not a call to change this particular patch, but rather a discussion on what to do next. Thomas
>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes: > Dear Yann E. MORIN, > On Wed, 20 Jan 2016 19:34:29 +0100, Yann E. MORIN wrote: >> Now that we can say that the linux headers version should match that of >> the kernel to be built, we inverse the logic in our defconfigs, as it is >> more sensible that way. >> >> And also because we'll get rid of the former, converse kernel-same-as-headers >> option. >> >> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > In this commit, you are changing the defconfigs that use > BR2_LINUX_KERNEL_SAME_AS_HEADERS. But I am wondering if we shouldn't > simply change *all* defconfigs to use this new feature. Essentially all > defconfigs have to worry about selecting a kernel headers version that > matches the kernel version they use. We could switch them all to use > your new mechanism, no? > Of course, this can be done as a separate effort, this is not a call > to change this particular patch, but rather a discussion on what to do > next. Agreed. As long as we use the internal toolchain for our defconfigs and build a kernel (and we so far always do), it makes sense to use this option.
Can we still have different header and kernel versions? As I understand it we have to rebuild the toolchain when we change header versions. So if I have a working embedded system based on kernel x and am trying to get a new one working with kernel x+1, I really don't want to change the kernel header version. In this case they should be backward compatible. And rebuilding the toolchain is such a pain that I always use an external toolchain, even if using the buildroot internal built one. So as long as I can still have separate header/kernel versions, I am happy with this change. Otherwise, it will be a pain with more full rebuilds. Regards, Steve
Thomas, All, On 2016-01-20 21:38 +0100, Thomas Petazzoni spake thusly: > On Wed, 20 Jan 2016 19:34:29 +0100, Yann E. MORIN wrote: > > Now that we can say that the linux headers version should match that of > > the kernel to be built, we inverse the logic in our defconfigs, as it is > > more sensible that way. > > > > And also because we'll get rid of the former, converse kernel-same-as-headers > > option. > > > > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> > > In this commit, you are changing the defconfigs that use > BR2_LINUX_KERNEL_SAME_AS_HEADERS. But I am wondering if we shouldn't > simply change *all* defconfigs to use this new feature. Essentially all > defconfigs have to worry about selecting a kernel headers version that > matches the kernel version they use. We could switch them all to use > your new mechanism, no? Well, I think it may be worse than that, in fact... Let's see what happens with a trivial defconfig from before this patch, with the default toolchain and the kernel settings: BR2_LINUX_KERNEL=y This would give: BR2_KERNEL_HEADERS_4_4=y BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.4" BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_LATEST_VERSION=y Now we use that defconfig after this patch, this gives: BR2_KERNEL_HEADERS_AS_KERNEL=y BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y BR2_LINUX_KERNEL=y BR2_LINUX_KERNEL_VERSION="4.4" And boom, we've lost BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y I have no idea how we could solve this. I doubt we want to add anything like BR2_LINUX_KERNEL_AT_LEAST_4_4 and the likes... :-/ Ideas? Regards, Yann E. MORIN.
Dear Steve Calfee, On Wed, 20 Jan 2016 13:37:56 -0800, Steve Calfee wrote: > Can we still have different header and kernel versions? > > As I understand it we have to rebuild the toolchain when we change > header versions. So if I have a working embedded system based on > kernel x and am trying to get a new one working with kernel x+1, I > really don't want to change the kernel header version. In this case > they should be backward compatible. And rebuilding the toolchain is > such a pain that I always use an external toolchain, even if using the > buildroot internal built one. > > So as long as I can still have separate header/kernel versions, I am > happy with this change. Otherwise, it will be a pain with more full > rebuilds. What Yann is adding is just another option to choose the kernel headers version. The other options (to use 4.4, a custom version, etc.) remain in place. Best regards, Thomas
Hello, On Wed, 20 Jan 2016 22:58:21 +0100, Yann E. MORIN wrote: > Well, I think it may be worse than that, in fact... Let's see what > happens with a trivial defconfig from before this patch, with the > default toolchain and the kernel settings: > > BR2_LINUX_KERNEL=y > > This would give: > > BR2_KERNEL_HEADERS_4_4=y > BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y > BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.4" > BR2_LINUX_KERNEL=y > BR2_LINUX_KERNEL_LATEST_VERSION=y > > Now we use that defconfig after this patch, this gives: > > BR2_KERNEL_HEADERS_AS_KERNEL=y > BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y > BR2_LINUX_KERNEL=y > BR2_LINUX_KERNEL_VERSION="4.4" > > And boom, we've lost BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y > > I have no idea how we could solve this. I doubt we want to add anything > like BR2_LINUX_KERNEL_AT_LEAST_4_4 and the likes... :-/ > > Ideas? Remove: default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL ? Thomas
Steve, All, On 2016-01-20 13:37 -0800, Steve Calfee spake thusly: > Can we still have different header and kernel versions? Yes! :-) > As I understand it we have to rebuild the toolchain when we change > header versions. So if I have a working embedded system based on > kernel x and am trying to get a new one working with kernel x+1, I > really don't want to change the kernel header version. In this case > they should be backward compatible. And rebuilding the toolchain is > such a pain that I always use an external toolchain, even if using the > buildroot internal built one. When you use an external toolchain, you can't use this new same-version-as-for-kernel option, since it is only available for the internal toolchain. For the external toolchain (even if built by Buildroot), you anyway have to tell what the kernel series the headers are from. > So as long as I can still have separate header/kernel versions, I am > happy with this change. Otherwise, it will be a pain with more full > rebuilds. No, it is just another option. Regards, Yann E. MORIN.
Thomas, All, On 2016-01-20 23:07 +0100, Thomas Petazzoni spake thusly: > On Wed, 20 Jan 2016 22:58:21 +0100, Yann E. MORIN wrote: > > Well, I think it may be worse than that, in fact... Let's see what > > happens with a trivial defconfig from before this patch, with the > > default toolchain and the kernel settings: > > > > BR2_LINUX_KERNEL=y > > > > This would give: > > > > BR2_KERNEL_HEADERS_4_4=y > > BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y > > BR2_TOOLCHAIN_HEADERS_AT_LEAST="4.4" > > BR2_LINUX_KERNEL=y > > BR2_LINUX_KERNEL_LATEST_VERSION=y > > > > Now we use that defconfig after this patch, this gives: > > > > BR2_KERNEL_HEADERS_AS_KERNEL=y > > BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_REALLY_OLD=y > > BR2_LINUX_KERNEL=y > > BR2_LINUX_KERNEL_VERSION="4.4" > > > > And boom, we've lost BR2_TOOLCHAIN_HEADERS_AT_LEAST_4_4=y > > > > I have no idea how we could solve this. I doubt we want to add anything > > like BR2_LINUX_KERNEL_AT_LEAST_4_4 and the likes... :-/ > > > > Ideas? > > Remove: > default BR2_KERNEL_HEADERS_AS_KERNEL if BR2_LINUX_KERNEL > ? Indeed. :-) Regards, Yann E. MORIN.
diff --git a/configs/freescale_imx28evk_defconfig b/configs/freescale_imx28evk_defconfig index 9ce5217..3f2f9e7 100644 --- a/configs/freescale_imx28evk_defconfig +++ b/configs/freescale_imx28evk_defconfig @@ -3,8 +3,6 @@ BR2_arm=y BR2_arm926t=y # toolchain -BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.19.2" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_19=y # system @@ -12,7 +10,8 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttyAMA0" # kernel BR2_LINUX_KERNEL=y -BR2_LINUX_KERNEL_SAME_AS_HEADERS=y +BR2_LINUX_KERNEL_CUSTOM_VERSION=y +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.19.2" BR2_LINUX_KERNEL_DEFCONFIG="mxs" BR2_LINUX_KERNEL_ZIMAGE=y BR2_LINUX_KERNEL_DTS_SUPPORT=y diff --git a/configs/freescale_imx31_3stack_defconfig b/configs/freescale_imx31_3stack_defconfig index 68781eb..ded6563 100644 --- a/configs/freescale_imx31_3stack_defconfig +++ b/configs/freescale_imx31_3stack_defconfig @@ -4,10 +4,6 @@ BR2_arm1136jf_s_r0=y BR2_ARM_EABIHF=y # toolchain -BR2_KERNEL_HEADERS_VERSION=y -# Note: sadly the Linux kernel will not boot on the i.MX31 PDK, starting with -# v3.16 and at least up to v4.0-rc4; this is why we use v3.15.y here. -BR2_DEFAULT_KERNEL_VERSION="3.15.10" BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_15=y # system @@ -15,7 +11,10 @@ BR2_TARGET_GENERIC_GETTY_PORT="ttymxc0" # kernel BR2_LINUX_KERNEL=y -BR2_LINUX_KERNEL_SAME_AS_HEADERS=y +# Note: sadly the Linux kernel will not boot on the i.MX31 PDK, starting with +# v3.16 and at least up to v4.0-rc4; this is why we use v3.15.y here. +BR2_LINUX_KERNEL_CUSTOM_VERSION=y +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.15.10" BR2_LINUX_KERNEL_DEFCONFIG="imx_v6_v7" BR2_LINUX_KERNEL_ZIMAGE=y BR2_TARGET_ROOTFS_CPIO_GZIP=y diff --git a/configs/ts5x00_defconfig b/configs/ts5x00_defconfig index befb655..6f140e6 100644 --- a/configs/ts5x00_defconfig +++ b/configs/ts5x00_defconfig @@ -1,19 +1,26 @@ +# architecture BR2_i386=y BR2_x86_i586=y -# Lock headers version to match and avoid breakage -BR2_KERNEL_HEADERS_VERSION=y -BR2_DEFAULT_KERNEL_VERSION="3.17.8" +# toolchain BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_3_17=y +# system BR2_TARGET_GENERIC_GETTY_PORT="ttyS1" BR2_ROOTFS_OVERLAY="board/ts/ts5x00/fs-overlay" + +# kernel BR2_LINUX_KERNEL=y -BR2_LINUX_KERNEL_SAME_AS_HEADERS=y +BR2_LINUX_KERNEL_CUSTOM_VERSION=y +BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="3.17.8" BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/ts/ts5x00/linux-3.17.config" BR2_LINUX_KERNEL_INSTALL_TARGET=y + +# rootfs BR2_TARGET_ROOTFS_EXT2=y BR2_TARGET_ROOTFS_EXT2_4=y + +# bootloader BR2_TARGET_SYSLINUX=y BR2_TARGET_SYSLINUX_MBR=y
Now that we can say that the linux headers version should match that of the kernel to be built, we inverse the logic in our defconfigs, as it is more sensible that way. And also because we'll get rid of the former, converse kernel-same-as-headers option. Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr> --- configs/freescale_imx28evk_defconfig | 5 ++--- configs/freescale_imx31_3stack_defconfig | 9 ++++----- configs/ts5x00_defconfig | 15 +++++++++++---- 3 files changed, 17 insertions(+), 12 deletions(-)