[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openembedded-core
Subject:    Re: [OE-core] [PATCH] kernel-yocto: log some kmeta information to assist in developing a bsp
From:       "Yann Dirson" <yann.dirson () blade-group ! com>
Date:       2021-03-31 14:44:30
Message-ID: CA+4=imb3m9e8JDJS6r8OxC-9Q1K3kEpKCSjBA2Xt2v=ESWPLbw () mail ! gmail ! com
[Download RAW message or body]

Le mer. 31 mars 2021 Ã  14:41, Bruce Ashfield
<bruce.ashfield@gmail.com> a écrit :
> 
> On Wed, Mar 31, 2021 at 6:23 AM Yann Dirson <yann.dirson@blade-group.com> wrote:
> > 
> > Le mar. 30 mars 2021 Ã  20:41, Yann Dirson via lists.openembedded.org
> > <yann.dirson=blade-group.com@lists.openembedded.org> a écrit :
> > > 
> > > Hi Bruce,
> > > 
> > > Le mar. 30 mars 2021 Ã  19:47, Bruce Ashfield
> > > <bruce.ashfield@gmail.com> a écrit :
> > > > 
> > > > On Tue, Mar 30, 2021 at 1:27 PM Yann Dirson <yann.dirson@blade-group.com> \
> > > > wrote:
> > > > > 
> > > > > From: Yann Dirson <yann@blade-group.com>
> > > > > 
> > > > > This is not quite enough for the lack of a BSP to stand out clearly to
> > > > > an unsuspecting user's eyes, but at least this line in the logs should
> > > > > help some of us to get a clue:
> > > > > 
> > > > > NOTE: Using kmeta BSP ''
> > > > 
> > > > Sorry, but no on this.
> > > > 
> > > > There are already logs that are kept in the build directories
> > > > themselves. They can be further exposed via some of the existing debug
> > > > knobs that I have, but this is just noise in the general logs.
> > > 
> > > I must say I did not find any existing logs on this, where can I find them ?
> > 
> > After some digging in the source I finally noticed the merge_config.sh
> > output being saved
> > under $meta_dir.  It still took me an additional log to locate the log
> > under work-shared/.../kernel-source/.
> > I'm pretty sure I was pointed to this file in the past, but I find it
> > unnecessarily difficult to locate.
> 
> As opposed to any of the other random log files that contain somewhat
> internal information ? This isn't something that the majority of people
> need to see, so it stays local to what the recipes are building (the
> kernel). The use facing distillation of that information is the kernel
> configuration audit.
> 
> In the past 10 years or so, I've bounced back and forth between
> exposing more information, getting complaints/comments about
> the amount of noise and fine tuning the signal to noise in the
> information. That's what is being balanced here.
> 
> > 
> > Still, this log does not contain the name of the top-level
> > $KMACHINE-$KTYPE.scc, which is the
> > information I'm after.
> 
> That's logged in a file in the .kernel-meta directory.
> (${S}/${meta_dir}/bsp_definition)
> 
> > 
> > I do agree however that it make it unnecessary to log the whole $elements list,
> > as long it is easy enough to locate the information.  Here is a
> > proposal to address this last point, so that
> > a user looking at the task logs gets the path to it.  Does that one
> > look OK to you ?
> > 
> 
> There's already a kernel config audit task, and that's where any enhanced
> information really needs to go.
> 
> There's no need to rush through anything on this, since we are right on top
> of a release, and although minor, I wouldn't push for it to go in at this point.
> 
> But I do agree, we can tweak things to expose a bit more information that
> aids in development of new BSPs/fragments than is currently available.

I understand that the details about the BSP contents don't get exposed to the
user by default.  However, it would look sane to me that the selected BSP would
be more visible: it is really important for people trying to use
different kernel
configurations on a given board, as the BSP selected when there is no
exact match
seems to require today to dive into the recipe-specific logs.

But in fact, when I select, say PREFERRED_PROVIDER_virtual/kernel =
"linux-yocto-rt"
for this nanopi-m4 for which I only added "standard" and "tiny":
kernel-source/.kernel-meta/bsp_definition then contains just an empty
line, ie. the
bbnote "Using kmeta BSP '$bsp_definition'" in my original patch seems
to give exactly
the same amount of information.

Isn't the actually-selected BSP available somewhere in this case ?  This ends up
with scsi configuration fragments being selected, but I have no clue
where they're
coming from:

$ cat /tmp/work-shared/nanopi-m4-2gb/kernel-source/.kernel-meta/config.queue
configs///defconfig # non-hardware
configs//features/netfilter/netfilter.cfg # non-hardware
configs//features/taskstats/taskstats.cfg # non-hardware
configs//features/scsi/scsi.cfg # hardware
configs//features/scsi/scsi-debug.cfg # hardware
configs//features/gpio/mockup.cfg # non-hardware


> 
> I can float some RFC patches in a few weeks and see if they meet the need.
> 
> Bruce
> 
> > diff --git a/meta/classes/kernel-yocto.bbclass
> > b/meta/classes/kernel-yocto.bbclass
> > index 9aa0eb07c6..e3efa34671 100644
> > --- a/meta/classes/kernel-yocto.bbclass
> > +++ b/meta/classes/kernel-yocto.bbclass
> > @@ -430,6 +430,8 @@ do_kernel_configme() {
> > else
> > bbfatal_log "Details can be found at:
> > ${S}/${meta_dir}/cfg/merge_config_build.log"
> > fi
> > +       else
> > +               bbnote "Detailed merge_config.sh output can be found
> > at: ${S}/${meta_dir}/cfg/merge_config_build.log"
> > fi
> > 
> > if [ ! -z "${LINUX_VERSION_EXTENSION}" ]; then
> > 
> > > 
> > > > 
> > > > Cheers,
> > > > 
> > > > Bruce
> > > > 
> > > > > 
> > > > > Signed-off-by: Yann Dirson <yann@blade-group.com>
> > > > > ---
> > > > > meta/classes/kernel-yocto.bbclass | 3 +++
> > > > > 1 file changed, 3 insertions(+)
> > > > > 
> > > > > diff --git a/meta/classes/kernel-yocto.bbclass \
> > > > > b/meta/classes/kernel-yocto.bbclass index 35587dd564..c6228ad0b8 100644
> > > > > --- a/meta/classes/kernel-yocto.bbclass
> > > > > +++ b/meta/classes/kernel-yocto.bbclass
> > > > > @@ -234,6 +234,7 @@ do_kernel_metadata() {
> > > > > KMETA_EXTERNAL_BSPS="t"
> > > > > fi
> > > > > fi
> > > > > +       bbnote "Using kmeta BSP '$bsp_definition'"
> > > > > meta_dir=$(kgit --meta)
> > > > > 
> > > > > KERNEL_FEATURES_FINAL=""
> > > > > @@ -264,6 +265,7 @@ do_kernel_metadata() {
> > > > > if [ "$mode" = "config" ]; then
> > > > > # run1: pull all the configuration fragments, no matter where they come \
> > > > > from elements="`echo -n ${bsp_definition} $sccs_defconfig ${sccs} \
> > > > > ${patches} $KERNEL_FEATURES_FINAL`" +               bbnote "config: kmeta \
> > > > > configuration fragments: $elements" if [ -n "${elements}" ]; then
> > > > > echo "${bsp_definition}" > ${S}/${meta_dir}/bsp_definition
> > > > > scc --force -o ${S}/${meta_dir}:cfg,merge,meta ${includes} $sccs_defconfig \
> > > > > $bsp_definition $sccs $patches $KERNEL_FEATURES_FINAL @@ -283,6 +285,7 @@ \
> > > > > do_kernel_metadata() { if [ "$mode" = "patch" ]; then
> > > > > # run2: only generate patches for elements that have been passed on the \
> > > > > SRC_URI elements="`echo -n ${sccs} ${patches} $KERNEL_FEATURES_FINAL`"
> > > > > +               bbnote "patch: kmeta configuration fragments: $elements"
> > > > > if [ -n "${elements}" ]; then
> > > > > scc --force -o ${S}/${meta_dir}:patch --cmds patch ${includes} ${sccs} \
> > > > > ${patches} $KERNEL_FEATURES_FINAL if [ $? -ne 0 ]; then
> > > > > --
> > > > > 2.30.2
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > --
> > > > - Thou shalt not follow the NULL pointer, for chaos and madness await
> > > > thee at its end
> > > > - "Use the force Harry" - Gandalf, Star Trek II
> > > 
> > > 
> > > 
> > > --
> > > Yann Dirson <yann@blade-group.com>
> > > Blade / Shadow -- http://shadow.tech
> > > 
> > > 
> > > 
> > 
> > 
> > --
> > Yann Dirson <yann@blade-group.com>
> > Blade / Shadow -- http://shadow.tech
> 
> 
> 
> --
> - Thou shalt not follow the NULL pointer, for chaos and madness await
> thee at its end
> - "Use the force Harry" - Gandalf, Star Trek II



-- 
Yann Dirson <yann@blade-group.com>
Blade / Shadow -- http://shadow.tech



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#150113): https://lists.openembedded.org/g/openembedded-core/message/150113
Mute This Topic: https://lists.openembedded.org/mt/81730505/4454766
Group Owner: openembedded-core+owner@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [openembedded-core@marc.info]
-=-=-=-=-=-=-=-=-=-=-=-



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic