All of lore.kernel.org
 help / color / mirror / Atom feed
From: Darren Hart <dvhart@linux.intel.com>
To: Bruce Ashfield <bruce.ashfield@windriver.com>
Cc: linux-yocto@yoctoproject.org, Rahul.Saxena@intel.com,
	openembedded-core@lists.openembedded.org
Subject: Re: [PATCH 7/8] kern-tools: flexibility and usability enhancements
Date: Wed, 14 Nov 2012 08:33:45 -0800	[thread overview]
Message-ID: <50A3C7E9.2000603@linux.intel.com> (raw)
In-Reply-To: <93224a342aad308f6d239566534b21b24c694c1c.1352840087.git.bruce.ashfield@windriver.com>



On 11/14/2012 07:03 AM, Bruce Ashfield wrote:
> Updating the SRCREV to import the following changes.
> 
>  [updateme: find the board description with the highest score]
> 
>    This removes the requirement that a custom linux-yocto .scc file have
>    define KTYPE <foo>, where <foo> is typically "standard". The tools can
>    now match on a .scc file that only matches the board, but will still
>    chose one that matches the board and kernel type, if available.

Should the documentation then state that KTYPE is only necessary to
define if it is not "standard" ? Does this also apply to
linux-yocto-custom recipes/kernels where the repository could very well
not define any ktype at all?

> 
>  [updateme: allow for tabs or spaces in defines]
> 
>    define KMACHINE<tab>$MACHINE was missed by the regex.
> 
>  [scc/kgit-meta: detect and avoid duplicating patching]
> 
>    To allow feature description to be included multiple times, they were
>    previously split into -enable and 'patch' descriptions. With this change
>    the patches will be detected as already included, and skipped
>    automatically. Removing the need to do this split. It also cleans up
>    the ability to warn about multiple includes.
> 
>  [kconf_check: add "verify" configuration fragment type]
> 
>    This adds the ability for a BSP to have a kernel configuration
>    fragment that lists options that must be present. If they are not
>    present it is a hard error. "required" is a similar fragment, but
>    it adds them to the build, and audits them at the end, but does
>    not abort the build if they are present. This is a minor distinction,
>    but one that is useful when creating flexible, shared kernel config
>    structures.


IIRC we discussed this verify thing at ELCE and how it broke some of the
semantics.... trying to remember now, let's see:

kconf hardware foo.cfg
kconf verify hardware bar.cfg
kconf non-hardware foobar.cfg
kconf verify non-hardware barfoo.cfg

Is that how this is to be used? The configuration space just doubled
from a documentation point of view, and that is without even considering
the "required" keyword you described.

Can you use required with verify? Can you use both of them with both
hardware and non-hardware?


> 
>  [kconf_check: improve kernel audit report formatting]
>  [kconf_check: perform validity checks on non-hardware options]
>  [kconf_check: cleanups and verbose flag]
> 
>    The existing output was verbose and not always useful to the reader.
>    This change makes the output more compact, audits non-hardware options
>    and gives information
> 
>      [invalid (54)]: meta/cfg/preempt-rt/common-pc/invalid.cfg
>         This BSP sets config options that are not offered anywhere within this kernel
> 
> Signed-off-by: Bruce Ashfield <bruce.ashfield@windriver.com>
> ---
>  meta/recipes-kernel/kern-tools/kern-tools-native_git.bb |    2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> index ce94885..f2cd39f 100644
> --- a/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> +++ b/meta/recipes-kernel/kern-tools/kern-tools-native_git.bb
> @@ -4,7 +4,7 @@ LIC_FILES_CHKSUM = "file://git/tools/kgit;beginline=5;endline=9;md5=d8d1d729a70c
>  
>  DEPENDS = "git-native guilt-native"
>  
> -SRCREV = "a802ee9c8d9334c0f7932dfd40d45599addb7c90"
> +SRCREV = "6f68c9473b43c3e39755a72aef8733cbd0bf1a59"
>  PR = "r12"
>  PV = "0.1+git${SRCPV}"
>  
> 

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel



  reply	other threads:[~2012-11-14 16:47 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-14 15:02 [PATCH 0/8] linux-yocto + kern tools consolidated pull request Bruce Ashfield
2012-11-14 15:02 ` [PATCH 1/8] linux-yocto/3.4: nfsd, pci, fishriver and rangely config changes Bruce Ashfield
2012-11-14 15:02 ` [PATCH 2/8] linux-yocto/3.4: efi/mmc fixes and fri2 updates Bruce Ashfield
2012-11-14 15:02 ` [PATCH 3/8] linux-yocto/3.4: bump kver to v3.4.16 Bruce Ashfield
2012-11-14 15:03 ` [PATCH 4/8] linux-yocto/3.4: v3.4.17, v3.4.18, -rt and config changes Bruce Ashfield
2012-11-14 15:03 ` [PATCH 5/8] linux-yocto/3.2: update to v3.2.32 and 3.2.32-rt48 Bruce Ashfield
2012-11-14 15:03 ` [PATCH 6/8] kern-tools: kconf_check: fix find warning Bruce Ashfield
2012-11-14 15:03 ` [PATCH 7/8] kern-tools: flexibility and usability enhancements Bruce Ashfield
2012-11-14 16:33   ` Darren Hart [this message]
2012-11-14 16:58     ` Bruce Ashfield
2012-11-14 17:09       ` Darren Hart
2012-11-14 17:32         ` Bruce Ashfield
2012-11-14 15:03 ` [PATCH 8/8] guilt: change upstream tgz location Bruce Ashfield
2012-11-20 19:50 ` [PATCH 0/8] linux-yocto + kern tools consolidated pull request Saul Wold

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50A3C7E9.2000603@linux.intel.com \
    --to=dvhart@linux.intel.com \
    --cc=Rahul.Saxena@intel.com \
    --cc=bruce.ashfield@windriver.com \
    --cc=linux-yocto@yoctoproject.org \
    --cc=openembedded-core@lists.openembedded.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.