Re: [PATCH 18/42] conf: bump minimum kernel to 3.2.0

[Ruslan Bilovol <rbilovol@cisco.com>]

Hi,

On 05/11/2016 08:35 PM, Khem Raj wrote:
> glibc 2.24 have raised the bar for minimum supported kernel
> for more details see
>
> http://repo.or.cz/glibc.git/commit/5b4ecd3f95695ef593e4474b4ab5a117291ba5fc
>
> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> ---
>   meta/classes/populate_sdk_base.bbclass | 2 +-
>   meta/conf/bitbake.conf                 | 2 +-
>   2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/meta/classes/populate_sdk_base.bbclass b/meta/classes/populate_sdk_base.bbclass
> index 008bb57..645a7f4 100644
> --- a/meta/classes/populate_sdk_base.bbclass
> +++ b/meta/classes/populate_sdk_base.bbclass
> @@ -90,7 +90,7 @@ SDK_POSTPROCESS_COMMAND = " create_sdk_files; check_sdk_sysroots; tar_sdk; ${SDK
>   # Some archs override this, we need the nativesdk version
>   # turns out this is hard to get from the datastore due to TRANSLATED_TARGET_ARCH
>   # manipulation.
> -SDK_OLDEST_KERNEL = "2.6.32"
> +SDK_OLDEST_KERNEL = "3.2.0"
>   
>   fakeroot python do_populate_sdk() {
>       from oe.sdk import populate_sdk
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index 8e02e91..07d171d 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -403,7 +403,7 @@ SDKPATHNATIVE = "${SDKPATH}/sysroots/${SDK_SYS}"
>   # Kernel info.
>   ##################################################################
>   
> -OLDEST_KERNEL = "2.6.32"
> +OLDEST_KERNEL = "3.2.0"
>   OLDEST_KERNEL_aarch64 = "3.14"
>   STAGING_KERNEL_DIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-source"
>   STAGING_KERNEL_BUILDDIR = "${TMPDIR}/work-shared/${MACHINE}/kernel-build-artifacts"
Could you please keep 2.6.32 for i386/x86_64? In mentioned glibc commit
http://repo.or.cz/glibc.git/commit/5b4ecd3f95695ef593e4474b4ab5a117291ba5fc
I see that Linux v3.2 is required for all architectures except x86 / x86_64.
Currently we build OE and use SDK on x86_64 hosts and some of them
run Linux based on kernel 2.6.32 so we would like to still have ability
to use OE/SDK on such machines

Thanks,
Ruslan