[RFC PATCH 0/6] Kernel configuration check for recipes

[RFC PATCH 0/6] Kernel configuration check for recipes

[Paul Eggleton]

Add the capability for other recipes to verify that kernel
configuration options they depend upon at runtime are present, and warn
if they are missing. This seems functional enough to me but is still in
RFC - please let me know if it looks OK to you or I've missed anything
(no doubt there are recipes we could add the checks to, I refer mainly
to the mechanism itself).


Please review the following changes for suitability for inclusion. If you have
any objections or suggestions for improvement, please respond to the patches. If
you agree with the changes, please provide your Acked-by.

The following changes since commit ece101be5158beee709cdfbb85ecdbdc8d9fb864:

  test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)

are available in the git repository at:

  git://git.openembedded.org/openembedded-core-contrib paule/kernel-check
  http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/kernel-check

Paul Eggleton (6):
  classes/kernel-check: add a class to check kernel config options
  eudev: check for required kernel config options
  systemd: check for required kernel config options
  classes/kernel: fix typo
  classes/kernel: check OLDEST_KERNEL at configure time
  classes/image: check kernel config supports IMAGE_FSTYPES items

 meta/classes/image.bbclass               | 23 ++++++++
 meta/classes/image_types.bbclass         | 11 ++++
 meta/classes/kernel-check.bbclass        | 97 ++++++++++++++++++++++++++++++++
 meta/classes/kernel.bbclass              | 16 +++++-
 meta/recipes-core/systemd/systemd_229.bb | 19 ++++++-
 meta/recipes-core/udev/eudev_3.1.5.bb    | 22 +++++++-
 6 files changed, 185 insertions(+), 3 deletions(-)
 create mode 100644 meta/classes/kernel-check.bbclass

-- 
2.5.5

[RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Paul Eggleton]

Some user-space software has specific requirements about the kernel
configuration options selected. This class allows a recipe to explicitly
state the kernel configuration options it needs (through a
REQUIRED_KERNEL_OPTIONS variable). This is a space separated list, where
each item is one of:
  (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
      must be set to y or m to match)
  (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
      CONFIG_FHANDLE must be set to y). If the specified value is n,
      it will also match if the option is not present.
  (c) optionname1|optionname2|... (e.g.
      CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
      CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
      m to match).

Inheriting the class will also add a dependency from do_configure on
virtual/kernel:do_shared_workdir so that the kernel config is there to
check. If one or more items are not matched, then a warning will be
printed at do_configure time. (This is a warning rather than an error
in case you are using linux-dummy with an externally built kernel).

A separate function is also provided should you wish to check a config
option from python code - but note you must only call this in a place
where you can guarantee that the kernel config has been written to the
sysroot (i.e. from a task that has virtual/kernel:do_shared_workdir in
its depends varflag value).

Fixes [YOCTO #5574].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel-check.bbclass | 97 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 97 insertions(+)
 create mode 100644 meta/classes/kernel-check.bbclass

diff --git a/meta/classes/kernel-check.bbclass b/meta/classes/kernel-check.bbclass
new file mode 100644
index 0000000..d202f4e
--- /dev/null
+++ b/meta/classes/kernel-check.bbclass
@@ -0,0 +1,97 @@
+# Provides a means of checking within a recipe if particular kernel
+# config options are enabled
+#
+# Copyright (C) 2016 Intel Corporation
+#
+# Example usage (within a recipe):
+#
+# inherit kernel-check
+# REQUIRED_KERNEL_OPTIONS = "CONFIG_CGROUPS CONFIG_NAMESPACES"
+#
+# If one or more of the options aren't in the built kernel configuration
+# you will get a warning at do_configure time.
+#
+# You can also use the check_kernel_config_options() function to do
+# explicit checks yourself (and perform a different action).
+
+def check_kernel_config_options(options, d):
+    """
+    A function you can use to do explicit checks for kernel config
+    options from python code
+    """
+
+    if isinstance(options, basestring):
+        required = options.split()
+    else:
+        required = options[:]
+    missing = []
+    diffvalue = []
+    if required:
+        with open(d.expand('${STAGING_KERNEL_BUILDDIR}/.config'), 'r') as f:
+            for line in f:
+                if line.startswith('#'):
+                    continue
+                linesplit = line.rstrip().split('=', 1)
+                if len(linesplit) < 2:
+                    continue
+                linevalue = linesplit[1]
+                for req in required:
+                    found = False
+                    if '|' in req:
+                        for reqitem in req.split('|'):
+                            if reqitem == linesplit[0]:
+                                if linevalue in ['y', 'm']:
+                                    found = True
+                                    break
+                    else:
+                        reqsplit = req.split('=', 1)
+                        # Can check for CONFIG_OPTION or CONFIG_OPTION=value
+                        if len(reqsplit) > 1:
+                            reqvalue = reqsplit[1]
+                        else:
+                            reqvalue = None
+                        if reqsplit[0] == linesplit[0]:
+                            if reqvalue is None:
+                                if linevalue not in ['y', 'm']:
+                                    diffvalue.append((reqsplit[0], 'y or m', linevalue))
+                            elif reqvalue.strip("'\"") != linevalue.strip("'\""):
+                                diffvalue.append((reqsplit[0], reqvalue, linevalue))
+                            found = True
+
+                    if found:
+                        required.remove(req)
+                        break
+
+        for req in required:
+            reqsplit = req.split('=', 1)
+            if len(reqsplit) > 1:
+                if reqsplit[1] == 'n':
+                    continue
+                missing.append('%s=%s' % reqsplit)
+            else:
+                missing.append('%s' % req)
+
+    return missing, diffvalue
+
+
+python check_kernel_config() {
+    pn = d.getVar('PN', True)
+    required = d.getVar('REQUIRED_KERNEL_OPTIONS', True) or ''
+    if ' | ' in required:
+        bb.error('Invalid REQUIRED_KERNEL_OPTIONS value - cannot have spaces around |')
+    if ' = ' in required:
+        bb.error('Invalid REQUIRED_KERNEL_OPTIONS value - cannot have spaces around =')
+    missing, diffvalue = check_kernel_config_options(required, d)
+    if missing or diffvalue:
+        reqstr = '\n  '.join(missing + ['%s=%s (actual value %s)' % item for item in diffvalue])
+        # Just warn here for cases like linux-dummy where we don't actually
+        # know the final config
+        bb.warn('The kernel you are building against is missing the following required configuration options:\n  %s' % reqstr)
+}
+
+python() {
+    if d.getVar('REQUIRED_KERNEL_OPTIONS', True):
+        d.appendVar('DEPENDS', ' virtual/kernel')
+        d.appendVarFlag('do_configure', 'prefuncs', ' check_kernel_config')
+        d.appendVarFlag('do_configure', 'depends', ' virtual/kernel:do_shared_workdir')
+}
-- 
2.5.5

[RFC PATCH 2/6] eudev: check for required kernel config options

[Paul Eggleton]

Use the list in the udev 220 README (since that is apparently what this
is equivalent to; unfortunately eudev doesn't provide the same document)
to set required Linux kernel config options, with the exception of
CONFIG_HOTPLUG which is always on for 3.11 and later kernels.

Fixes [YOCTO #5574].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-core/udev/eudev_3.1.5.bb | 22 +++++++++++++++++++++-
 1 file changed, 21 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/udev/eudev_3.1.5.bb b/meta/recipes-core/udev/eudev_3.1.5.bb
index e42630f..41d72f6 100644
--- a/meta/recipes-core/udev/eudev_3.1.5.bb
+++ b/meta/recipes-core/udev/eudev_3.1.5.bb
@@ -23,7 +23,27 @@ UPSTREAM_CHECK_URI = "https://github.com/gentoo/eudev/releases"
 SRC_URI[md5sum] = "e130f892d8744e292cb855db79935f68"
 SRC_URI[sha256sum] = "ce9d5fa91e3a42c7eb95512ca0fa2a631e89833053066bb6cdf42046b2a88553"
 
-inherit autotools update-rc.d qemu
+inherit autotools update-rc.d qemu kernel-check
+
+# All the required options from the udev README
+# (except for CONFIG_HOTPLUG which is always on in
+# 3.11 and later kernels.)
+REQUIRED_KERNEL_OPTIONS = "\
+                           CONFIG_DEVTMPFS \
+                           CONFIG_CGROUPS \
+                           CONFIG_INOTIFY_USER \
+                           CONFIG_SIGNALFD \
+                           CONFIG_TIMERFD \
+                           CONFIG_EPOLL \
+                           CONFIG_NET \
+                           CONFIG_SYSFS \
+                           CONFIG_SYSFS_DEPRECATED=n \
+                           CONFIG_SYSFS_DEPRECATED_V2=n \
+                           CONFIG_PROC_FS \
+                           CONFIG_FHANDLE \
+                           CONFIG_UEVENT_HELPER_PATH='' \
+                           CONFIG_FW_LOADER_USER_HELPER=n \
+                           "
 
 EXTRA_OECONF = " \
     --sbindir=${base_sbindir} \
-- 
2.5.5

[RFC PATCH 3/6] systemd: check for required kernel config options

[Paul Eggleton]

Use the list in the systemd 225 README to set required Linux kernel
config options.

Fixes [YOCTO #5574].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/recipes-core/systemd/systemd_229.bb | 19 ++++++++++++++++++-
 1 file changed, 18 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_229.bb b/meta/recipes-core/systemd/systemd_229.bb
index c23c749..d64b3cd 100644
--- a/meta/recipes-core/systemd/systemd_229.bb
+++ b/meta/recipes-core/systemd/systemd_229.bb
@@ -22,7 +22,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl rea
 
 SECTION = "base/shell"
 
-inherit useradd pkgconfig autotools perlnative update-rc.d update-alternatives qemu systemd ptest gettext bash-completion
+inherit useradd pkgconfig autotools perlnative update-rc.d update-alternatives qemu systemd ptest gettext bash-completion kernel-check
 
 SRCREV = "714c62b46379abb7558c544665522aca91691e10"
 
@@ -192,6 +192,23 @@ CFLAGS .= "${@bb.utils.contains('PACKAGECONFIG', 'valgrind', ' -DVALGRIND=1', ''
 # disable problematic GCC 5.2 optimizations [YOCTO #8291]
 FULL_OPTIMIZATION_append_arm = " -fno-schedule-insns -fno-schedule-insns2"
 
+# All the required options from the systemd README
+REQUIRED_KERNEL_OPTIONS = "\
+                           CONFIG_DEVTMPFS \
+                           CONFIG_CGROUPS \
+                           CONFIG_INOTIFY_USER \
+                           CONFIG_SIGNALFD \
+                           CONFIG_TIMERFD \
+                           CONFIG_EPOLL \
+                           CONFIG_NET \
+                           CONFIG_SYSFS \
+                           CONFIG_PROC_FS \
+                           CONFIG_FHANDLE \
+                           CONFIG_SYSFS_DEPRECATED=n \
+                           CONFIG_UEVENT_HELPER_PATH='' \
+                           CONFIG_FW_LOADER_USER_HELPER=n \
+                           "
+
 do_configure_prepend() {
 	export NM="${HOST_PREFIX}gcc-nm"
 	export AR="${HOST_PREFIX}gcc-ar"
-- 
2.5.5

[RFC PATCH 4/6] classes/kernel: fix typo

[Paul Eggleton]

KERNEL_VERISON -> KERNEL_VERSION (in a comment)

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index 6e3e81e..fa0864c 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -361,7 +361,7 @@ inherit cml1
 EXPORT_FUNCTIONS do_compile do_install do_configure
 
 # kernel-base becomes kernel-${KERNEL_VERSION}
-# kernel-image becomes kernel-image-${KERNEL_VERISON}
+# kernel-image becomes kernel-image-${KERNEL_VERSION}
 PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
 FILES_${PN} = ""
 FILES_kernel-base = "/lib/modules/${KERNEL_VERSION}/modules.order /lib/modules/${KERNEL_VERSION}/modules.builtin"
-- 
2.5.5

[RFC PATCH 5/6] classes/kernel: check OLDEST_KERNEL at configure time

[Paul Eggleton]

If the kernel being built is older than OLDEST_KERNEL and we're building
with glibc, then the C library we're building is probably not going to
be compatible with the kernel and we should warn the user. (This is
easier to do here rather than when building glibc, because we don't
necessarily have the information we need to determine the kernel version
there, whereas we do here.)

Fixes [YOCTO #8653].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/kernel.bbclass | 14 ++++++++++++++
 1 file changed, 14 insertions(+)

diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
index fa0864c..af88cc0 100644
--- a/meta/classes/kernel.bbclass
+++ b/meta/classes/kernel.bbclass
@@ -330,6 +330,20 @@ sysroot_stage_all () {
 
 KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} O=${B} oldnoconfig || yes '' | oe_runmake -C ${S} O=${B} oldconfig"
 
+python check_oldest_kernel() {
+    oldest_kernel = d.getVar('OLDEST_KERNEL', True)
+    kernel_version = d.getVar('KERNEL_VERSION', True)
+    tclibc = d.getVar('TCLIBC', True)
+    if tclibc == 'glibc':
+        kernel_version = kernel_version.split('-', 1)[0]
+        if oldest_kernel and kernel_version:
+            if bb.utils.vercmp_string(kernel_version, oldest_kernel) < 0:
+                bb.warn('%s: OLDEST_KERNEL is "%s" but the version of the kernel you are building is "%s" - therefore %s as built may not be compatible with this kernel. Either set OLDEST_KERNEL to an older version, or build a newer kernel.' % (d.getVar('PN', True), oldest_kernel, kernel_version, tclibc))
+}
+
+check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
+do_configure[prefuncs] += "check_oldest_kernel"
+
 kernel_do_configure() {
 	# fixes extra + in /lib/modules/2.6.37+
 	# $ scripts/setlocalversion . => +
-- 
2.5.5

[RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Paul Eggleton]

A lot of the IMAGE_FSTYPES items require the appropriate filesystem
driver to be enabled in the kernel configuration; e.g. in order to read
a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
to ensure that is the case.

Fixes [YOCTO #5574].

Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
---
 meta/classes/image.bbclass       | 23 +++++++++++++++++++++++
 meta/classes/image_types.bbclass | 11 +++++++++++
 2 files changed, 34 insertions(+)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 4542e95..c56b053 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -238,9 +238,32 @@ do_rootfs[cleandirs] += "${S}"
 do_rootfs[umask] = "022"
 addtask rootfs before do_build
 
+inherit kernel-check
+
+def check_image_fstypes_kernel(d):
+    """
+    Check that the kernel we have built has the appropriate config options enabled
+    to support the image formats specified in IMAGE_FSTYPES
+    """
+    fstypes = (d.getVar('IMAGE_FSTYPES', True) or '').split()
+    ctypes = (d.getVar('COMPRESSIONTYPES', True) or '').split()
+    for fstype in fstypes:
+        kernconfig = (d.getVar('IMAGE_TYPE_KERNEL_OPTIONS_' + fstype, True) or '').split()
+        for ctype in ctypes:
+            if fstype.endswith("." + ctype):
+                basetype = fstype[:-len("." + ctype)]
+                kernconfig.extend((d.getVar('IMAGE_TYPE_KERNEL_OPTIONS_' + basetype, True) or '').split())
+        kernconfig = list(set(kernconfig))
+        if kernconfig:
+            missing, diffvalue = check_kernel_config_options(kernconfig, d)
+            if missing or diffvalue:
+                bb.warn('IMAGE_FSTYPES contains %s, but the following required kernel configuration items are not present in the kernel configuration:\n  %s' % (fstype, '\n  '.join(missing + ['%s=%s (actual value %s)' % item for item in diffvalue])))
+
 fakeroot python do_image () {
     from oe.utils import execute_pre_post_process
 
+    check_image_fstypes_kernel(d)
+
     pre_process_cmds = d.getVar("IMAGE_PREPROCESS_COMMAND", True)
 
     execute_pre_post_process(d, pre_process_cmds)
diff --git a/meta/classes/image_types.bbclass b/meta/classes/image_types.bbclass
index 53af7ca..dd79726 100644
--- a/meta/classes/image_types.bbclass
+++ b/meta/classes/image_types.bbclass
@@ -240,6 +240,17 @@ IMAGE_DEPENDS_ubifs = "mtd-utils-native"
 IMAGE_DEPENDS_multiubi = "mtd-utils-native"
 IMAGE_DEPENDS_wic = "parted-native"
 
+IMAGE_TYPE_KERNEL_OPTIONS_jffs2 = "CONFIG_JFFS2_FS"
+IMAGE_TYPE_KERNEL_OPTIONS_jffs2.sum = "CONFIG_JFFS2_SUMMARY"
+IMAGE_TYPE_KERNEL_OPTIONS_cramfs = "CONFIG_CRAMFS"
+IMAGE_TYPE_KERNEL_OPTIONS_ext2 = "CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23"
+IMAGE_TYPE_KERNEL_OPTIONS_ext3 = "CONFIG_EXT3_FS|CONFIG_EXT4_USE_FOR_EXT23"
+IMAGE_TYPE_KERNEL_OPTIONS_ext4 = "CONFIG_EXT4_FS"
+IMAGE_TYPE_KERNEL_OPTIONS_btrfs = "CONFIG_BTRFS_FS"
+IMAGE_TYPE_KERNEL_OPTIONS_squashfs = "CONFIG_SQUASHFS"
+IMAGE_TYPE_KERNEL_OPTIONS_squashfs-xz = "CONFIG_SQUASHFS_XZ"
+IMAGE_TYPE_KERNEL_OPTIONS_squashfs-lzo = "CONFIG_SQUASHFS_LZO"
+
 # This variable is available to request which values are suitable for IMAGE_FSTYPES
 IMAGE_TYPES = " \
     jffs2 jffs2.sum \
-- 
2.5.5

Re: [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 6936 bytes --]

On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> Some user-space software has specific requirements about the kernel
> configuration options selected. This class allows a recipe to explicitly
> state the kernel configuration options it needs (through a
> REQUIRED_KERNEL_OPTIONS variable). This is a space separated list, where
> each item is one of:
>   (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
>       must be set to y or m to match)
>   (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
>       CONFIG_FHANDLE must be set to y). If the specified value is n,
>       it will also match if the option is not present.
>   (c) optionname1|optionname2|... (e.g.
>       CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
>       CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
>       m to match).
>


This duplicates code that is already in the kconf_check routines, which
I've already
made generic (and added dependency information) for the 2.2 release ... so
call
me confused that I've never heard about this until now :(

Bruce


>
> Inheriting the class will also add a dependency from do_configure on
> virtual/kernel:do_shared_workdir so that the kernel config is there to
> check. If one or more items are not matched, then a warning will be
> printed at do_configure time. (This is a warning rather than an error
> in case you are using linux-dummy with an externally built kernel).
>
> A separate function is also provided should you wish to check a config
> option from python code - but note you must only call this in a place
> where you can guarantee that the kernel config has been written to the
> sysroot (i.e. from a task that has virtual/kernel:do_shared_workdir in
> its depends varflag value).
>
> Fixes [YOCTO #5574].
>
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  meta/classes/kernel-check.bbclass | 97
> +++++++++++++++++++++++++++++++++++++++
>  1 file changed, 97 insertions(+)
>  create mode 100644 meta/classes/kernel-check.bbclass
>
> diff --git a/meta/classes/kernel-check.bbclass
> b/meta/classes/kernel-check.bbclass
> new file mode 100644
> index 0000000..d202f4e
> --- /dev/null
> +++ b/meta/classes/kernel-check.bbclass
> @@ -0,0 +1,97 @@
> +# Provides a means of checking within a recipe if particular kernel
> +# config options are enabled
> +#
> +# Copyright (C) 2016 Intel Corporation
> +#
> +# Example usage (within a recipe):
> +#
> +# inherit kernel-check
> +# REQUIRED_KERNEL_OPTIONS = "CONFIG_CGROUPS CONFIG_NAMESPACES"
> +#
> +# If one or more of the options aren't in the built kernel configuration
> +# you will get a warning at do_configure time.
> +#
> +# You can also use the check_kernel_config_options() function to do
> +# explicit checks yourself (and perform a different action).
> +
> +def check_kernel_config_options(options, d):
> +    """
> +    A function you can use to do explicit checks for kernel config
> +    options from python code
> +    """
> +
> +    if isinstance(options, basestring):
> +        required = options.split()
> +    else:
> +        required = options[:]
> +    missing = []
> +    diffvalue = []
> +    if required:
> +        with open(d.expand('${STAGING_KERNEL_BUILDDIR}/.config'), 'r') as
> f:
> +            for line in f:
> +                if line.startswith('#'):
> +                    continue
> +                linesplit = line.rstrip().split('=', 1)
> +                if len(linesplit) < 2:
> +                    continue
> +                linevalue = linesplit[1]
> +                for req in required:
> +                    found = False
> +                    if '|' in req:
> +                        for reqitem in req.split('|'):
> +                            if reqitem == linesplit[0]:
> +                                if linevalue in ['y', 'm']:
> +                                    found = True
> +                                    break
> +                    else:
> +                        reqsplit = req.split('=', 1)
> +                        # Can check for CONFIG_OPTION or
> CONFIG_OPTION=value
> +                        if len(reqsplit) > 1:
> +                            reqvalue = reqsplit[1]
> +                        else:
> +                            reqvalue = None
> +                        if reqsplit[0] == linesplit[0]:
> +                            if reqvalue is None:
> +                                if linevalue not in ['y', 'm']:
> +                                    diffvalue.append((reqsplit[0], 'y or
> m', linevalue))
> +                            elif reqvalue.strip("'\"") !=
> linevalue.strip("'\""):
> +                                diffvalue.append((reqsplit[0], reqvalue,
> linevalue))
> +                            found = True
> +
> +                    if found:
> +                        required.remove(req)
> +                        break
> +
> +        for req in required:
> +            reqsplit = req.split('=', 1)
> +            if len(reqsplit) > 1:
> +                if reqsplit[1] == 'n':
> +                    continue
> +                missing.append('%s=%s' % reqsplit)
> +            else:
> +                missing.append('%s' % req)
> +
> +    return missing, diffvalue
> +
> +
> +python check_kernel_config() {
> +    pn = d.getVar('PN', True)
> +    required = d.getVar('REQUIRED_KERNEL_OPTIONS', True) or ''
> +    if ' | ' in required:
> +        bb.error('Invalid REQUIRED_KERNEL_OPTIONS value - cannot have
> spaces around |')
> +    if ' = ' in required:
> +        bb.error('Invalid REQUIRED_KERNEL_OPTIONS value - cannot have
> spaces around =')
> +    missing, diffvalue = check_kernel_config_options(required, d)
> +    if missing or diffvalue:
> +        reqstr = '\n  '.join(missing + ['%s=%s (actual value %s)' % item
> for item in diffvalue])
> +        # Just warn here for cases like linux-dummy where we don't
> actually
> +        # know the final config
> +        bb.warn('The kernel you are building against is missing the
> following required configuration options:\n  %s' % reqstr)
> +}
> +
> +python() {
> +    if d.getVar('REQUIRED_KERNEL_OPTIONS', True):
> +        d.appendVar('DEPENDS', ' virtual/kernel')
> +        d.appendVarFlag('do_configure', 'prefuncs', '
> check_kernel_config')
> +        d.appendVarFlag('do_configure', 'depends', '
> virtual/kernel:do_shared_workdir')
> +}
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 8983 bytes --]

Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 4656 bytes --]

On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> driver to be enabled in the kernel configuration; e.g. in order to read
> a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> to ensure that is the case.
>


So what's the overall design for this ? Is it documented anywhere ? This is
something
that we talked about a couple of years and I have reservations and
objections to
the current implementation.

.. but since I can only see bits and chunks of patches, I'd rather read
something
complete and offer some more detailed feedback.

Bottom line: I see a slippery slope to tightly specified option that depend
on kernel
versions, I see kernel options sprayed all over layers, etc, etc. Which is
exactly
what we've been trying to avoid with the centralized kernel meta-data, and
again,
there's a mechanism that I finished early this year to extend those options
to any
kernel, enforce, warn, error, etc .. but now, I'll just toss it into the
bin.

Cheers,

Bruce


>
> Fixes [YOCTO #5574].
>
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
>  meta/classes/image.bbclass       | 23 +++++++++++++++++++++++
>  meta/classes/image_types.bbclass | 11 +++++++++++
>  2 files changed, 34 insertions(+)
>
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 4542e95..c56b053 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -238,9 +238,32 @@ do_rootfs[cleandirs] += "${S}"
>  do_rootfs[umask] = "022"
>  addtask rootfs before do_build
>
> +inherit kernel-check
> +
> +def check_image_fstypes_kernel(d):
> +    """
> +    Check that the kernel we have built has the appropriate config
> options enabled
> +    to support the image formats specified in IMAGE_FSTYPES
> +    """
> +    fstypes = (d.getVar('IMAGE_FSTYPES', True) or '').split()
> +    ctypes = (d.getVar('COMPRESSIONTYPES', True) or '').split()
> +    for fstype in fstypes:
> +        kernconfig = (d.getVar('IMAGE_TYPE_KERNEL_OPTIONS_' + fstype,
> True) or '').split()
> +        for ctype in ctypes:
> +            if fstype.endswith("." + ctype):
> +                basetype = fstype[:-len("." + ctype)]
> +                kernconfig.extend((d.getVar('IMAGE_TYPE_KERNEL_OPTIONS_'
> + basetype, True) or '').split())
> +        kernconfig = list(set(kernconfig))
> +        if kernconfig:
> +            missing, diffvalue = check_kernel_config_options(kernconfig,
> d)
> +            if missing or diffvalue:
> +                bb.warn('IMAGE_FSTYPES contains %s, but the following
> required kernel configuration items are not present in the kernel
> configuration:\n  %s' % (fstype, '\n  '.join(missing + ['%s=%s (actual
> value %s)' % item for item in diffvalue])))
> +
>  fakeroot python do_image () {
>      from oe.utils import execute_pre_post_process
>
> +    check_image_fstypes_kernel(d)
> +
>      pre_process_cmds = d.getVar("IMAGE_PREPROCESS_COMMAND", True)
>
>      execute_pre_post_process(d, pre_process_cmds)
> diff --git a/meta/classes/image_types.bbclass
> b/meta/classes/image_types.bbclass
> index 53af7ca..dd79726 100644
> --- a/meta/classes/image_types.bbclass
> +++ b/meta/classes/image_types.bbclass
> @@ -240,6 +240,17 @@ IMAGE_DEPENDS_ubifs = "mtd-utils-native"
>  IMAGE_DEPENDS_multiubi = "mtd-utils-native"
>  IMAGE_DEPENDS_wic = "parted-native"
>
> +IMAGE_TYPE_KERNEL_OPTIONS_jffs2 = "CONFIG_JFFS2_FS"
> +IMAGE_TYPE_KERNEL_OPTIONS_jffs2.sum = "CONFIG_JFFS2_SUMMARY"
> +IMAGE_TYPE_KERNEL_OPTIONS_cramfs = "CONFIG_CRAMFS"
> +IMAGE_TYPE_KERNEL_OPTIONS_ext2 =
> "CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23"
> +IMAGE_TYPE_KERNEL_OPTIONS_ext3 =
> "CONFIG_EXT3_FS|CONFIG_EXT4_USE_FOR_EXT23"
> +IMAGE_TYPE_KERNEL_OPTIONS_ext4 = "CONFIG_EXT4_FS"
> +IMAGE_TYPE_KERNEL_OPTIONS_btrfs = "CONFIG_BTRFS_FS"
> +IMAGE_TYPE_KERNEL_OPTIONS_squashfs = "CONFIG_SQUASHFS"
> +IMAGE_TYPE_KERNEL_OPTIONS_squashfs-xz = "CONFIG_SQUASHFS_XZ"
> +IMAGE_TYPE_KERNEL_OPTIONS_squashfs-lzo = "CONFIG_SQUASHFS_LZO"
> +
>  # This variable is available to request which values are suitable for
> IMAGE_FSTYPES
>  IMAGE_TYPES = " \
>      jffs2 jffs2.sum \
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 6179 bytes --]

Re: [RFC PATCH 0/6] Kernel configuration check for recipes

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3058 bytes --]

On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
paul.eggleton@linux.intel.com> wrote:

> Add the capability for other recipes to verify that kernel
> configuration options they depend upon at runtime are present, and warn
> if they are missing. This seems functional enough to me but is still in
> RFC - please let me know if it looks OK to you or I've missed anything
> (no doubt there are recipes we could add the checks to, I refer mainly
> to the mechanism itself).
>
>
> Please review the following changes for suitability for inclusion. If you
> have
> any objections or suggestions for improvement, please respond to the
> patches. If
> you agree with the changes, please provide your Acked-by.
>
>
See my replies to the patches. I'm sure it won't matter in the end, but
this is a duplication
of the mechanisms that we already have in the kernel config check phase. I
have a whole
set of changes that I completed early this year that extends that mechanism
to any kernel
(not just kernel-yocto) classes. In that mechanism there's the concept of
"required" and
"optional" Kconfig options. If they aren't present in the final .config, we
warn and optionally
error (this is versus the currently mechanism of only warning if boot
critical options are
dropped).

I'm betting that the follow on to this series will be "Hey recipes should
set the options for the kernel if
they really need them" .. which IMHO is an incredibly bad idea.

Cheers,

Bruce


> The following changes since commit
> ece101be5158beee709cdfbb85ecdbdc8d9fb864:
>
>   test-empty-image: Fix LIC_FILES_CHKSUM typo (2016-05-06 10:47:59 +0100)
>
> are available in the git repository at:
>
>   git://git.openembedded.org/openembedded-core-contrib paule/kernel-check
>
> http://cgit.openembedded.org/cgit.cgi/openembedded-core-contrib/log/?h=paule/kernel-check
>
> Paul Eggleton (6):
>   classes/kernel-check: add a class to check kernel config options
>   eudev: check for required kernel config options
>   systemd: check for required kernel config options
>   classes/kernel: fix typo
>   classes/kernel: check OLDEST_KERNEL at configure time
>   classes/image: check kernel config supports IMAGE_FSTYPES items
>
>  meta/classes/image.bbclass               | 23 ++++++++
>  meta/classes/image_types.bbclass         | 11 ++++
>  meta/classes/kernel-check.bbclass        | 97
> ++++++++++++++++++++++++++++++++
>  meta/classes/kernel.bbclass              | 16 +++++-
>  meta/recipes-core/systemd/systemd_229.bb | 19 ++++++-
>  meta/recipes-core/udev/eudev_3.1.5.bb    | 22 +++++++-
>  6 files changed, 185 insertions(+), 3 deletions(-)
>  create mode 100644 meta/classes/kernel-check.bbclass
>
> --
> 2.5.5
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 4492 bytes --]

Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Christopher Larson]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield <bruce.ashfield@gmail.com>
wrote:

> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
>
>> A lot of the IMAGE_FSTYPES items require the appropriate filesystem
>> driver to be enabled in the kernel configuration; e.g. in order to read
>> a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
>> to ensure that is the case.
>>
>
>
> So what's the overall design for this ? Is it documented anywhere ? This
> is something
> that we talked about a couple of years and I have reservations and
> objections to
> the current implementation.
>
> .. but since I can only see bits and chunks of patches, I'd rather read
> something
> complete and offer some more detailed feedback.
>
> Bottom line: I see a slippery slope to tightly specified option that
> depend on kernel
> versions, I see kernel options sprayed all over layers, etc, etc. Which is
> exactly
> what we've been trying to avoid with the centralized kernel meta-data, and
> again,
> there's a mechanism that I finished early this year to extend those
> options to any
> kernel, enforce, warn, error, etc .. but now, I'll just toss it into the
> bin.
>

Perhaps this functionality should be by feature or capability rather than
individual options, and let the kernel build determine what features it
provides based on its configuration.
-- 
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics

[-- Attachment #2: Type: text/html, Size: 2274 bytes --]

Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3406 bytes --]

On Mon, May 9, 2016 at 12:57 PM, Christopher Larson <clarson@kergoth.com>
wrote:

>
> On Mon, May 9, 2016 at 5:05 AM, Bruce Ashfield <bruce.ashfield@gmail.com>
> wrote:
>
>> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
>> paul.eggleton@linux.intel.com> wrote:
>>
>>> A lot of the IMAGE_FSTYPES items require the appropriate filesystem
>>> driver to be enabled in the kernel configuration; e.g. in order to read
>>> a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
>>> to ensure that is the case.
>>>
>>
>>
>> So what's the overall design for this ? Is it documented anywhere ? This
>> is something
>> that we talked about a couple of years and I have reservations and
>> objections to
>> the current implementation.
>>
>> .. but since I can only see bits and chunks of patches, I'd rather read
>> something
>> complete and offer some more detailed feedback.
>>
>> Bottom line: I see a slippery slope to tightly specified option that
>> depend on kernel
>> versions, I see kernel options sprayed all over layers, etc, etc. Which
>> is exactly
>> what we've been trying to avoid with the centralized kernel meta-data,
>> and again,
>> there's a mechanism that I finished early this year to extend those
>> options to any
>> kernel, enforce, warn, error, etc .. but now, I'll just toss it into the
>> bin.
>>
>
> Perhaps this functionality should be by feature or capability rather than
> individual options, and let the kernel build determine what features it
> provides based on its configuration.
>

You hit the nail on the head with that comment. There are some old bugzilla
lurking around
about distro -> kernel options (aka kernel features) that I've suggested a
similar concept
(or even machine features -> kernel).

IMHO some level of abstraction is needed for both, since otherwise we end
up tightly
coupling recipes to a machine and kernel combination.

Someone can ask for a specific option all they like, but unless they know
the details
of the kernel provider .. they are basically making a guess, and someone
working with
many different types of recipes shouldn't have to know the details of every
kernel tree
they are building. Sure it isn't widespread, or a lot of recipes, but again
.. I see a slippery
slope.

In the case kernel doesn't have it they fail (or if they've specified
something wrong), but
there are often substitutions that can be performed .. or optional
features, etc.  If there's some
level of abstraction, the kernel provider itself can turn on the right
options, avoid common / minor
errors, make suggestions and ensure that the h/w (and kernel) actually has
the capability.

The h/w actually having the capability is a significant issue for me as
well, since asking for
something .. but not actually having the required h/w (or arch) support,
and having no way
to abstractly figure out if something is supported .. means that even more
knowledge of
the kernel and the machine starts slipping into recipes and ends up being
spread all around
the layer stack.

Cheers,

Bruce




>
> --
> Christopher Larson
> clarson at kergoth dot com
> Founder - BitBake, OpenEmbedded, OpenZaurus
> Maintainer - Tslib
> Senior Software Engineer, Mentor Graphics
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 4932 bytes --]

Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Paul Eggleton]

Hi Bruce,

On Mon, 09 May 2016 08:05:06 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
> > A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> > driver to be enabled in the kernel configuration; e.g. in order to read
> > a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> > to ensure that is the case.
> 
> So what's the overall design for this ? Is it documented anywhere ? This is
> something that we talked about a couple of years and I have reservations and
> objections to the current implementation.
> 
> .. but since I can only see bits and chunks of patches, I'd rather read
> something complete and offer some more detailed feedback.
> 
> Bottom line: I see a slippery slope to tightly specified option that depend
> on kernel versions, I see kernel options sprayed all over layers, etc, etc.
> Which is exactly what we've been trying to avoid with the centralized kernel
> meta-data, and again, there's a mechanism that I finished early this year to
> extend those options to any kernel, enforce, warn, error, etc .. but now,
> I'll just toss it into the bin.

There's no design written out beyond what you see in the associated bug:

  https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574

The situation I am trying to avoid is the exact one mentioned by a commenter 
on that bug - which is that if I build my rootfs in a particular way, and 
couple it with a particular kernel configuration, I want the build system to 
tell me if those are going to be incompatible. The current situation where the 
you don't find out until the system doesn't boot (and you may not get any 
meaningful error message at that point anyway) isn't great.

You mention hardware in your reply to Chris, but this mostly isn't about 
hardware - it's about dependencies on software features of the kernel from 
userspace. I'm perfectly happy if we go for alternative solution, but to my 
mind whatever solution we come up with needs to be something whereby if you 
enable something in userspace that the kernel as currently configured isn't 
going to be able to support, you at least get a warning at build time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Paul Eggleton]

On Mon, 09 May 2016 07:59:43 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> paul.eggleton@linux.intel.com> wrote:
> > Some user-space software has specific requirements about the kernel
> > configuration options selected. This class allows a recipe to explicitly
> > state the kernel configuration options it needs (through a
> > REQUIRED_KERNEL_OPTIONS variable). This is a space separated list, where
> > 
> > each item is one of:
> >   (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
> >   
> >       must be set to y or m to match)
> >   
> >   (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
> >   
> >       CONFIG_FHANDLE must be set to y). If the specified value is n,
> >       it will also match if the option is not present.
> >   
> >   (c) optionname1|optionname2|... (e.g.
> >   
> >       CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
> >       CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
> >       m to match).
> 
> This duplicates code that is already in the kconf_check routines, which
> I've already made generic (and added dependency information) for the 2.2
> release ... so call me confused that I've never heard about this until now 
> :(

I guess I didn't look hard enough, I'll have to take a look at that. This is 
why the series is RFC (and I included you on CC ;)

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC PATCH 0/6] Kernel configuration check for recipes

[Paul Eggleton]

On Mon, 09 May 2016 08:08:55 Bruce Ashfield wrote:
> On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> 
> paul.eggleton@linux.intel.com> wrote:
> > Add the capability for other recipes to verify that kernel
> > configuration options they depend upon at runtime are present, and warn
> > if they are missing. This seems functional enough to me but is still in
> > RFC - please let me know if it looks OK to you or I've missed anything
> > (no doubt there are recipes we could add the checks to, I refer mainly
> > to the mechanism itself).
> > 
> > 
> > Please review the following changes for suitability for inclusion. If you
> > have
> > any objections or suggestions for improvement, please respond to the
> > patches. If
> > you agree with the changes, please provide your Acked-by.
> 
> See my replies to the patches. I'm sure it won't matter in the end, but
> this is a duplication of the mechanisms that we already have in the kernel
> config check phase. I have a whole set of changes that I completed early
> this year that extends that mechanism to any kernel (not just kernel-yocto)
> classes. In that mechanism there's the concept of "required" and
> "optional" Kconfig options. If they aren't present in the final .config, we
> warn and optionally error (this is versus the currently mechanism of only
> warning if boot critical options are dropped).

OK - so I guess this gets down to the question of whether we can practically 
define all of these userspace dependencies on the kernel side rather than 
individual recipes. I actually couldn't tell you how many other recipes this 
might be useful in - systemd and udev are where it's come up numerous times 
for users, and IMAGE_FSTYPES was one that I could think of. Perhaps we ought 
to analyse that in greater detail before proceeding.

> I'm betting that the follow on to this series will be "Hey recipes should
> set the options for the kernel if they really need them" .. which IMHO is an
> incredibly bad idea.

We'll never be getting to that level. Fundamentally one recipe cannot 
influence the configuration of another, at least not directly, and I agree in 
this case it wouldn't make any sense. I'm just proposing a check here.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [RFC PATCH 6/6] classes/image: check kernel config supports IMAGE_FSTYPES items

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 3550 bytes --]

On Mon, May 9, 2016 at 4:45 PM, Paul Eggleton <paul.eggleton@linux.intel.com
> wrote:

> Hi Bruce,
>
> On Mon, 09 May 2016 08:05:06 Bruce Ashfield wrote:
> > On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> > paul.eggleton@linux.intel.com> wrote:
> > > A lot of the IMAGE_FSTYPES items require the appropriate filesystem
> > > driver to be enabled in the kernel configuration; e.g. in order to read
> > > a btrfs filesystem, the kernel must enable CONFIG_BTRFS_FS. Add a check
> > > to ensure that is the case.
> >
> > So what's the overall design for this ? Is it documented anywhere ? This
> is
> > something that we talked about a couple of years and I have reservations
> and
> > objections to the current implementation.
> >
> > .. but since I can only see bits and chunks of patches, I'd rather read
> > something complete and offer some more detailed feedback.
> >
> > Bottom line: I see a slippery slope to tightly specified option that
> depend
> > on kernel versions, I see kernel options sprayed all over layers, etc,
> etc.
> > Which is exactly what we've been trying to avoid with the centralized
> kernel
> > meta-data, and again, there's a mechanism that I finished early this
> year to
> > extend those options to any kernel, enforce, warn, error, etc .. but now,
> > I'll just toss it into the bin.
>
> There's no design written out beyond what you see in the associated bug:
>
>   https://bugzilla.yoctoproject.org/show_bug.cgi?id=5574
>
> The situation I am trying to avoid is the exact one mentioned by a
> commenter
> on that bug - which is that if I build my rootfs in a particular way, and
> couple it with a particular kernel configuration, I want the build system
> to
> tell me if those are going to be incompatible. The current situation where
> the
> you don't find out until the system doesn't boot (and you may not get any
> meaningful error message at that point anyway) isn't great.
>
> You mention hardware in your reply to Chris, but this mostly isn't about
> hardware - it's about dependencies on software features of the kernel from
>

I only brought up h/w to point out the slippery slope, and that if you are
going to
solve one class of options, eventually it will lead to someone asking for
others
and then the ability to set them. We then have a tight binding and
distributed
knowledge of the kernel specifics.


> userspace. I'm perfectly happy if we go for alternative solution, but to my
> mind whatever solution we come up with needs to be something whereby if you
> enable something in userspace that the kernel as currently configured isn't
> going to be able to support, you at least get a warning at build time.
>

What you describe is almost exactly what KERNEL_FEATURES + the existing
Kconfig
audit does. That mechanism does the audit for software and h/w features via
a level
of abstraction (the name of the feature, versus the kernel options
themselves).

I'm about 75% of the way to extended that to any kernel (not just
linux-yocto) and
exposing the "required" and "optional" kconfig support (that has been
around for
about 1.5 years .. just no one has asked for it :D

That's why I'm trying to understand what exactly is missing and is being
solved
here, so I can decide whether to drop my changes or not.

Bruce


>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 4813 bytes --]

Re: [RFC PATCH 1/6] classes/kernel-check: add a class to check kernel config options

[Bruce Ashfield]

[-- Attachment #1: Type: text/plain, Size: 2023 bytes --]

On Mon, May 9, 2016 at 4:53 PM, Paul Eggleton <paul.eggleton@linux.intel.com
> wrote:

> On Mon, 09 May 2016 07:59:43 Bruce Ashfield wrote:
> > On Mon, May 9, 2016 at 12:43 AM, Paul Eggleton <
> > paul.eggleton@linux.intel.com> wrote:
> > > Some user-space software has specific requirements about the kernel
> > > configuration options selected. This class allows a recipe to
> explicitly
> > > state the kernel configuration options it needs (through a
> > > REQUIRED_KERNEL_OPTIONS variable). This is a space separated list,
> where
> > >
> > > each item is one of:
> > >   (a) an option name (e.g. CONFIG_FHANDLE, in which case CONFIG_FHANDLE
> > >
> > >       must be set to y or m to match)
> > >
> > >   (b) optionname=value (e.g. CONFIG_FHANDLE=y, in which case
> > >
> > >       CONFIG_FHANDLE must be set to y). If the specified value is n,
> > >       it will also match if the option is not present.
> > >
> > >   (c) optionname1|optionname2|... (e.g.
> > >
> > >       CONFIG_EXT2_FS|CONFIG_EXT4_USE_FOR_EXT23, meaning that either
> > >       CONFIG_EXT2_FS or CONFIG_EXT4_USE_FOR_EXT23 must be set to y or
> > >       m to match).
> >
> > This duplicates code that is already in the kconf_check routines, which
> > I've already made generic (and added dependency information) for the 2.2
> > release ... so call me confused that I've never heard about this until
> now
> > :(
>
> I guess I didn't look hard enough, I'll have to take a look at that. This
> is
> why the series is RFC (and I included you on CC ;)
>

Noted :) I read the patches before the 0/N .. and it was Monday morning
before coffee.

Don't look TOO closely as your eyes will bleed, but the basics are there.
My recent
work has been to clean it up so I can apply it to an arbitrary kernel.

Bruce


>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await thee
at its end"

[-- Attachment #2: Type: text/html, Size: 2988 bytes --]

Re: [RFC PATCH 3/6] systemd: check for required kernel config options

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2542 bytes --]


> On May 8, 2016, at 9:43 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 
> Use the list in the systemd 225 README to set required Linux kernel
> config options.
> 
> Fixes [YOCTO #5574].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/recipes-core/systemd/systemd_229.bb | 19 ++++++++++++++++++-
> 1 file changed, 18 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_229.bb b/meta/recipes-core/systemd/systemd_229.bb
> index c23c749..d64b3cd 100644
> --- a/meta/recipes-core/systemd/systemd_229.bb
> +++ b/meta/recipes-core/systemd/systemd_229.bb
> @@ -22,7 +22,7 @@ DEPENDS = "kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl rea
> 
> SECTION = "base/shell"
> 
> -inherit useradd pkgconfig autotools perlnative update-rc.d update-alternatives qemu systemd ptest gettext bash-completion
> +inherit useradd pkgconfig autotools perlnative update-rc.d update-alternatives qemu systemd ptest gettext bash-completion kernel-check
> 
> SRCREV = "714c62b46379abb7558c544665522aca91691e10"
> 
> @@ -192,6 +192,23 @@ CFLAGS .= "${@bb.utils.contains('PACKAGECONFIG', 'valgrind', ' -DVALGRIND=1', ''
> # disable problematic GCC 5.2 optimizations [YOCTO #8291]
> FULL_OPTIMIZATION_append_arm = " -fno-schedule-insns -fno-schedule-insns2"
> 
> +# All the required options from the systemd README
> +REQUIRED_KERNEL_OPTIONS = "\
> +                           CONFIG_DEVTMPFS \
> +                           CONFIG_CGROUPS \
> +                           CONFIG_INOTIFY_USER \
> +                           CONFIG_SIGNALFD \
> +                           CONFIG_TIMERFD \
> +                           CONFIG_EPOLL \
> +                           CONFIG_NET \
> +                           CONFIG_SYSFS \
> +                           CONFIG_PROC_FS \
> +                           CONFIG_FHANDLE \
> +                           CONFIG_SYSFS_DEPRECATED=n \
> +                           CONFIG_UEVENT_HELPER_PATH='' \
> +                           CONFIG_FW_LOADER_USER_HELPER=n \

We still carry the patch for user fw loader. So this may be removed.

> +                           "
> +
> do_configure_prepend() {
> 	export NM="${HOST_PREFIX}gcc-nm"
> 	export AR="${HOST_PREFIX}gcc-ar"
> --
> 2.5.5
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]

Re: [RFC PATCH 5/6] classes/kernel: check OLDEST_KERNEL at configure time

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2334 bytes --]


> On May 8, 2016, at 9:43 PM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote:
> 
> If the kernel being built is older than OLDEST_KERNEL and we're building
> with glibc, then the C library we're building is probably not going to
> be compatible with the kernel and we should warn the user. (This is
> easier to do here rather than when building glibc, because we don't
> necessarily have the information we need to determine the kernel version
> there, whereas we do here.)
> 
> Fixes [YOCTO #8653].
> 
> Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
> ---
> meta/classes/kernel.bbclass | 14 ++++++++++++++
> 1 file changed, 14 insertions(+)
> 
> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass
> index fa0864c..af88cc0 100644
> --- a/meta/classes/kernel.bbclass
> +++ b/meta/classes/kernel.bbclass
> @@ -330,6 +330,20 @@ sysroot_stage_all () {
> 
> KERNEL_CONFIG_COMMAND ?= "oe_runmake_call -C ${S} O=${B} oldnoconfig || yes '' | oe_runmake -C ${S} O=${B} oldconfig"
> 
> +python check_oldest_kernel() {
> +    oldest_kernel = d.getVar('OLDEST_KERNEL', True)
> +    kernel_version = d.getVar('KERNEL_VERSION', True)
> +    tclibc = d.getVar('TCLIBC', True)
> +    if tclibc == 'glibc':
> +        kernel_version = kernel_version.split('-', 1)[0]
> +        if oldest_kernel and kernel_version:
> +            if bb.utils.vercmp_string(kernel_version, oldest_kernel) < 0:
> +                bb.warn('%s: OLDEST_KERNEL is "%s" but the version of the kernel you are building is "%s" - therefore %s as built may not be compatible with this kernel. Either set OLDEST_KERNEL to an older version, or build a newer kernel.' % (d.getVar('PN', True), oldest_kernel, kernel_version, tclibc))
> +}

this should be an error infact. system may not boot properly if someone ignored the warning.

> +
> +check_oldest_kernel[vardepsexclude] += "OLDEST_KERNEL KERNEL_VERSION"
> +do_configure[prefuncs] += "check_oldest_kernel"
> +
> kernel_do_configure() {
> 	# fixes extra + in /lib/modules/2.6.37+
> 	# $ scripts/setlocalversion . => +
> --
> 2.5.5
> 
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 211 bytes --]