Skip to contentSkip to conversation

kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG

PATCH In review Saul Wold 2 participants 10 messages Nov 29, 2017 – Dec 1, 2017

lore
Share & tools
lore

Saul Wold

author
#0 lore raw

PATCH 1/2 kernel-yocto: ensure sccs variable is set when using KBUILD_DEFCONFIG

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig regardless if it compares or is copied. Otherwise $sccs is not set and the defconfig is not found correctly.

Part of
[YOCTO #12162]

---
 meta/classes/kernel-yocto.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +1 -1
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
 				fi
 			else
 				cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
-				sccs="${WORKDIR}/defconfig"
 			fi
+			sccs="${WORKDIR}/defconfig"
 		else
 			bbfatal "A KBUILD_DEFCONFIG '${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
 		fi
Signature · 1 line
2.13.6
author
#1 lore raw

PATCH 2/2 kernel-yocto: Stop the build if defconfig is missing

The bberror does not stop the build correctly, this should be a bbfatal_log to ensure the failure correctly stops the build and logs the failure.

Part of
[YOCTO #12162]

---
 meta/classes/kernel-yocto.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +1 -1
index 98ec78fb768..2edf0fd1578 100644
@@ -146,7 +146,7 @@ do_kernel_metadata() {
 	if [ -z "$bsp_definition" ]; then
 		echo "$sccs" | grep -q defconfig
 		if [ $? -ne 0 ]; then
-			bberror "Could not locate BSP definition for ${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
+			bbfatal_log "Could not locate BSP definition for ${KMACHINE}/${LINUX_KERNEL_TYPE} and no defconfig was provided"
 		fi
 	fi
 	meta_dir=$(kgit --meta)
Signature · 1 line
2.13.6
#2 lore raw
In reply to Saul Wold

Let me take both these into my queue for some extra testing.

I have some other changes that could interact with them.

But they do look fine to me .. I'd just like to test them and put them in my pull request.

Bruce

Quoted 27 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig regardless if it compares or is copied. Otherwise $sccs is not set and the defconfig is not found correctly.

Part of
[YOCTO #12162]

---
  meta/classes/kernel-yocto.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +1 -1
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
  				fi
  			else
  				cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
-				sccs="${WORKDIR}/defconfig"
  			fi
+			sccs="${WORKDIR}/defconfig"
  		else
  			bbfatal "A KBUILD_DEFCONFIG '${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
  		fi
#3 lore raw
In reply to Saul Wold
Quoted 3 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig regardless if it compares or is copied. Otherwise $sccs is not set and the defconfig is not found correctly.

Actually, looking at this more today, and this morning in my testing. This shouldn't be necessary .. it doesn't hurt anything (well, actually it could end up with two defconfigs in the variable, but that also should be ok).

Quoted 14 lines

Part of
[YOCTO #12162]

---
  meta/classes/kernel-yocto.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644

meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 114

Quoted 6 lines
meta/classes/kernel-yocto.bbclass +1 -1
@@ -110,8 +110,8 @@ do_kernel_metadata() {
  				fi
  			else
  				cp -f ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig
-				sccs="${WORKDIR}/defconfig"
  			fi
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

   if [ -f "${WORKDIR}/defconfig" ]; then

and then:

cmp "${WORKDIR}/defconfig"
"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by the time this runs, is if the fetcher puts it there. Which means it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

        sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 4 lines
meta/classes/kernel-yocto.bbclass +0 -0
  		else
  			bbfatal "A KBUILD_DEFCONFIG '${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
  		fi
author
#4 lore raw
Quoted 7 lines · Bruce Ashfield
Quoted 5 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set and the
defconfig is not found correctly.

Quoted 6 lines

Actually, looking at this more today, and this morning in my testing. This shouldn't be necessary .. it doesn't hurt anything (well, actually
it could end up with two defconfigs in the variable, but that also should be ok).

Ok, I understand, it's in find_sccs() where if you have "defconfig" in the SRC_URI then with my change you could end up with two defconfigs.

The problem I saw was if one just sets KBUILD_DEFCONFIG and does not set any config info on the SRC_URI then it's possible for $sccs to be empty, which was bad.

Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?

Sau!

Quoted 55 lines
Quoted 19 lines

Part of
[YOCTO #12162]

---
  meta/classes/kernel-yocto.bbclass | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
  				fi
  			else
  				cp -f

${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig

meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 114

Quoted 3 lines
meta/classes/kernel-yocto.bbclass +1 -1
-				sccs="${WORKDIR}/defconfig"
  			fi
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

    if [ -f "${WORKDIR}/defconfig" ]; then

and then:

   cmp "${WORKDIR}/defconfig" 

"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by the time this runs, is if the fetcher puts it there. Which means it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

         sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 6 lines

else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
fi

#5 lore raw
Quoted 14 lines · Saul Wold
Quoted 7 lines · Bruce Ashfield
Quoted 5 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set and the
defconfig is not found correctly.

Quoted 6 lines

Actually, looking at this more today, and this morning in my testing. This shouldn't be necessary .. it doesn't hurt anything (well, actually
it could end up with two defconfigs in the variable, but that also should be ok).

Quoted 6 lines

Ok, I understand, it's in find_sccs() where if you have "defconfig" in the SRC_URI then with my change you could end up with two defconfigs.

The problem I saw was if one just sets KBUILD_DEFCONFIG and does not set any config info on the SRC_URI then it's possible for $sccs to be empty, which was bad.

I took a look at the conditions again, and I can't see that path. But that doesn't mean it isn't there, is this a configuration that I can build and see myself ?

Quoted 3 lines

Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?

Yah, regardless of my above statement, it certainly wouldn't hurt and would be a good safeguard, since two defconfigs would trigger a M x N configuration audit of options (where M and N could be in the thousands) .. and hence, take a long time.

Bruce

Quoted 58 lines

Sau!

Quoted 55 lines
Quoted 19 lines

Part of
[YOCTO #12162]

---
   meta/classes/kernel-yocto.bbclass | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
   				fi
   			else
   				cp -f

${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG} ${WORKDIR}/defconfig

meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 114

Quoted 3 lines
meta/classes/kernel-yocto.bbclass +1 -1
-				sccs="${WORKDIR}/defconfig"
   			fi
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

     if [ -f "${WORKDIR}/defconfig" ]; then

and then:

    cmp "${WORKDIR}/defconfig"

"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by the time this runs, is if the fetcher puts it there. Which means it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

          sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 6 lines

else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source tree"
fi

author
#6 lore raw
Quoted 30 lines · Bruce Ashfield
Quoted 23 lines · Saul Wold
Quoted 8 lines · Bruce Ashfield
Quoted 6 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set
and the
defconfig is not found correctly.

Quoted 8 lines

Actually, looking at this more today, and this morning in my testing.
This shouldn't be necessary .. it doesn't hurt anything (well, actually
it could end up with two defconfigs in the variable, but that also
should be ok).

Ok, I understand, it's in find_sccs() where if you have "defconfig" in
the SRC_URI then with my change you could end up with two defconfigs.

Quoted 5 lines

The problem I saw was if one just sets KBUILD_DEFCONFIG and does not
set any config info on the SRC_URI then it's possible for $sccs to be
empty, which was bad.

Quoted 4 lines

I took a look at the conditions again, and I can't see that path. But that doesn't mean it isn't there, is this a configuration that I can build and see myself ?

Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does not have any defconfig, .scc or .cfg files. Build once that will populate the $WORKDIR/defconfig with vai the else path of the first if and the cp path in the do_kernel_metadata() code. Build a second time and the $WORKDIR/defconfig exists now and the first part of the if with the cmp will occur and the defconfig will not be found because $sccs does not get set in the original code when the cmp is equal.

Sau!

Quoted 74 lines
Quoted 4 lines

Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?

Yah, regardless of my above statement, it certainly wouldn't hurt and would be a good safeguard, since two defconfigs would trigger a M x N configuration audit of options (where M and N could be in the thousands) .. and hence, take a long time.

Bruce

Quoted 60 lines

Sau!

Quoted 57 lines
Quoted 20 lines

Part of
[YOCTO #12162]

---
   meta/classes/kernel-yocto.bbclass | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
   				fi
   			else
   				cp -f
 ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}

${WORKDIR}/defconfig

meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 114

Quoted 3 lines
meta/classes/kernel-yocto.bbclass +1 -1
-				sccs="${WORKDIR}/defconfig"
   			fi
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

     if [ -f "${WORKDIR}/defconfig" ]; then

and then:

    cmp "${WORKDIR}/defconfig"

"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by the time this runs, is if the fetcher puts it there. Which means it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

          sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 7 lines

else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source
tree"
fi

#7 lore raw
Quoted 35 lines · Saul Wold
Quoted 30 lines · Bruce Ashfield
Quoted 23 lines · Saul Wold
Quoted 8 lines · Bruce Ashfield
Quoted 6 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not set
and the
defconfig is not found correctly.

Quoted 8 lines

Actually, looking at this more today, and this morning in my testing.
This shouldn't be necessary .. it doesn't hurt anything (well, actually
it could end up with two defconfigs in the variable, but that also
should be ok).

Ok, I understand, it's in find_sccs() where if you have "defconfig" in
the SRC_URI then with my change you could end up with two defconfigs.

Quoted 5 lines

The problem I saw was if one just sets KBUILD_DEFCONFIG and does not
set any config info on the SRC_URI then it's possible for $sccs to be
empty, which was bad.

Quoted 4 lines

I took a look at the conditions again, and I can't see that path. But that doesn't mean it isn't there, is this a configuration that I can build and see myself ?

Quoted 7 lines

Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does not have any defconfig, .scc or .cfg files. Build once that will populate the $WORKDIR/defconfig with vai the else path of the first if and the cp path in the do_kernel_metadata() code. Build a second time and the $WORKDIR/defconfig exists now and the first part of the if with the cmp will occur and the defconfig will not be found because $sccs does not get set in the original code when the cmp is equal.

That's the ticket .. I didn't think of a 2nd pass through the build.

So with that extra assignment + a duplicate removal, it should be safe for all the paths.

Did you want to send a v2, or did you want me to make that tweak?

Either way, I'll continue testing here.

Bruce

Quoted 77 lines

Sau!

Quoted 74 lines
Quoted 4 lines

Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?

Yah, regardless of my above statement, it certainly wouldn't hurt and would be a good safeguard, since two defconfigs would trigger a M x N configuration audit of options (where M and N could be in the thousands) .. and hence, take a long time.

Bruce

Quoted 60 lines

Sau!

Quoted 57 lines
Quoted 20 lines

Part of
[YOCTO #12162]

---
    meta/classes/kernel-yocto.bbclass | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
    				fi
    			else
    				cp -f
 ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}

${WORKDIR}/defconfig

meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 114

Quoted 3 lines
meta/classes/kernel-yocto.bbclass +1 -1
-				sccs="${WORKDIR}/defconfig"
    			fi
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

      if [ -f "${WORKDIR}/defconfig" ]; then

and then:

     cmp "${WORKDIR}/defconfig"

"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by the time this runs, is if the fetcher puts it there. Which means it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

           sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 7 lines

else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source
tree"
fi

author
#8 lore raw
Quoted 57 lines · Bruce Ashfield
Quoted 42 lines · Saul Wold
Quoted 35 lines · Bruce Ashfield
Quoted 26 lines · Saul Wold
Quoted 9 lines · Bruce Ashfield
Quoted 7 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not
set
and the
defconfig is not found correctly.

Quoted 9 lines

Actually, looking at this more today, and this morning in my testing.
This shouldn't be necessary .. it doesn't hurt anything (well,
actually
it could end up with two defconfigs in the variable, but that also
should be ok).

Ok, I understand, it's in find_sccs() where if you have "defconfig"
in
the SRC_URI then with my change you could end up with two defconfigs.

Quoted 7 lines

The problem I saw was if one just sets KBUILD_DEFCONFIG and does
not
set any config info on the SRC_URI then it's possible for $sccs to
be
empty, which was bad.

Quoted 5 lines

I took a look at the conditions again, and I can't see that path. But that doesn't mean it isn't there, is this a configuration
that I can build and see myself ?

Quoted 13 lines

Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does not
have any defconfig, .scc or .cfg files. Build once that will populate
the $WORKDIR/defconfig with vai the else path of the first if and the
cp path in the do_kernel_metadata() code. Build a second time and the
$WORKDIR/defconfig exists now and the first part of the if with the cmp
will occur and the defconfig will not be found because $sccs does not
get set in the original code when the cmp is equal.

Quoted 8 lines

That's the ticket .. I didn't think of a 2nd pass through the build.

So with that extra assignment + a duplicate removal, it should be safe for all the paths.

Did you want to send a v2, or did you want me to make that tweak?

If you have the tweak in mind already, might be better for you to make it.

Thanks
Sau!

Quoted 87 lines

Either way, I'll continue testing here.

Bruce

Quoted 81 lines

Sau!

Quoted 78 lines
Quoted 4 lines

Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?

Yah, regardless of my above statement, it certainly wouldn't hurt and would be a good safeguard, since two defconfigs would trigger a M x N configuration audit of options (where M and N could be in the thousands) .. and hence, take a long time.

Bruce

Quoted 64 lines

Sau!

Quoted 61 lines
Quoted 23 lines

Part of
[YOCTO #12162]

---
    meta/classes/kernel-yocto.bbclass | 2 +-
    1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
    				fi
    			else
    				cp -f
 ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}

${WORKDIR}/defconfig

meta/classes/kernel-yocto.bbclass +0 -1
-				sccs="${WORKDIR}/defconfig

"
fi

meta/classes/kernel-yocto.bbclass do_kernel_metadata() { · line 114

Quoted 1 line
meta/classes/kernel-yocto.bbclass +1 -0
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

      if [ -f "${WORKDIR}/defconfig" ]; then

and then:

     cmp "${WORKDIR}/defconfig"

"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by
the time this runs, is if the fetcher puts it there. Which means
it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

           sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 7 lines

else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source
tree"
fi

#9 lore raw
Quoted 61 lines · Saul Wold
Quoted 60 lines · Bruce Ashfield
Quoted 42 lines · Saul Wold
Quoted 35 lines · Bruce Ashfield
Quoted 26 lines · Saul Wold
Quoted 9 lines · Bruce Ashfield
Quoted 7 lines · Saul Wold

When using KBUILD_DEFCONFIG, $sccs should be set to the $WORKDIR/defconfig
regardless if it compares or is copied. Otherwise $sccs is not
set
and the
defconfig is not found correctly.

Quoted 9 lines

Actually, looking at this more today, and this morning in my testing.
This shouldn't be necessary .. it doesn't hurt anything (well,
actually
it could end up with two defconfigs in the variable, but that also
should be ok).

Ok, I understand, it's in find_sccs() where if you have "defconfig"
in
the SRC_URI then with my change you could end up with two defconfigs.

Quoted 7 lines

The problem I saw was if one just sets KBUILD_DEFCONFIG and does
not
set any config info on the SRC_URI then it's possible for $sccs to
be
empty, which was bad.

Quoted 5 lines

I took a look at the conditions again, and I can't see that path. But that doesn't mean it isn't there, is this a configuration
that I can build and see myself ?

Quoted 13 lines

Set KBUILD_DEFCONFIG to some kernel defconfig, ensure SRC_URI does not
have any defconfig, .scc or .cfg files. Build once that will populate
the $WORKDIR/defconfig with vai the else path of the first if and the
cp path in the do_kernel_metadata() code. Build a second time and the
$WORKDIR/defconfig exists now and the first part of the if with the cmp
will occur and the defconfig will not be found because $sccs does not
get set in the original code when the cmp is equal.

That's the ticket .. I didn't think of a 2nd pass through the build.

Quoted 8 lines
Quoted 5 lines

So with that extra assignment + a duplicate removal, it should be safe for all the paths.

Did you want to send a v2, or did you want me to make that tweak?

If you have the tweak in mind already, might be better for you to make it.

One more question, since I'm still not able to trigger the issue here.

When you are getting the failure mode, is the:

bbwarn "defconfig detected in WORKDIR ..." being triggered ?

I actually think it would be better if I flip that warning around and always overwrite what is in WORKDIR if someone is using the KBUILD_DEFCONFIG functionality.

But for now, I will just remove the potential duplicate defconfig and ponder that change in functionality more.

Bruce

Quoted 90 lines

Thanks
Sau!

Quoted 87 lines

Either way, I'll continue testing here.

Bruce

Quoted 81 lines

Sau!

Quoted 78 lines
Quoted 4 lines

Maybe a cleaning of multiple "defconfig" entries on $sccs is needed?

Yah, regardless of my above statement, it certainly wouldn't hurt and would be a good safeguard, since two defconfigs would trigger a M x N configuration audit of options (where M and N could be in the thousands) .. and hence, take a long time.

Bruce

Quoted 64 lines

Sau!

Quoted 61 lines
Quoted 23 lines

Part of
[YOCTO #12162]

---
     meta/classes/kernel-yocto.bbclass | 2 +-
     1 file changed, 1 insertion(+), 1 deletion(-)
meta/classes/kernel-yocto.bbclass +0 -0
index 1d447951c49..98ec78fb768 100644
@@ -110,8 +110,8 @@ do_kernel_metadata() {
     				fi
     			else
     				cp -f
 ${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}

${WORKDIR}/defconfig

meta/classes/kernel-yocto.bbclass +0 -1
-				sccs="${WORKDIR}/defconfig

"
fi

meta/classes/kernel-yocto.bbclass

Quoted 1 line
meta/classes/kernel-yocto.bbclass +1 -0
+			sccs="${WORKDIR}/defconfig"

The test that was protecting this assignment is:

       if [ -f "${WORKDIR}/defconfig" ]; then

and then:

      cmp "${WORKDIR}/defconfig"

"${S}/arch/${ARCH}/configs/${KBUILD_DEFCONFIG}"

The only way that a defconfig can be in ${WORKDIR}/defconfig by
the time this runs, is if the fetcher puts it there. Which means
it is on the SRC_URI and comes from the recipe writer's layer.

There is existing code that already picks this up and adds it to the configuration queue:

            sccs="$sccs ${@" ".join(find_sccs(d))}"

So that defconfig, is already going to be picked up directly from the SRC_URI.

Bruce

Quoted 7 lines

else
bbfatal "A KBUILD_DEFCONFIG
'${KBUILD_DEFCONFIG}' was specified, but not present in the source
tree"
fi