[PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[Saul Wold]

The image bbclass will try to find the kernel-abiversion file which is not part
of the linux-dummy kernel since there is no actual kernel. In this case using
depmod also does not make sense since there should not be any kernel module built.

[YOCTO #7884]

Signed-off-by: Saul Wold <sgw@linux.intel.com>
---
 meta/classes/image.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 01f8b3f..be245e9 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
 EXCLUDE_FROM_WORLD = "1"
 
 USE_DEVFS ?= "1"
-USE_DEPMOD ?= "1"
+USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'
 
 PID = "${@os.getpid()}"
 
-- 
2.1.0

Re: [PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[Richard Purdie]

On Tue, 2015-06-23 at 12:22 -0700, Saul Wold wrote:
> The image bbclass will try to find the kernel-abiversion file which is not part
> of the linux-dummy kernel since there is no actual kernel. In this case using
> depmod also does not make sense since there should not be any kernel module built.
> 
> [YOCTO #7884]
> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
>  meta/classes/image.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 01f8b3f..be245e9 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
>  EXCLUDE_FROM_WORLD = "1"
>  
>  USE_DEVFS ?= "1"
> -USE_DEPMOD ?= "1"
> +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'
>  

I'm not convinced this is the right way to solve this. How about we
teach the code in rootfs.py not to generate a modules.dep file if there
are no kernel modules to generate dependency information for?

Cheers,

Richard

Re: [PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[Saul Wold]

On 06/23/2015 02:53 PM, Richard Purdie wrote:
> On Tue, 2015-06-23 at 12:22 -0700, Saul Wold wrote:
>> The image bbclass will try to find the kernel-abiversion file which is not part
>> of the linux-dummy kernel since there is no actual kernel. In this case using
>> depmod also does not make sense since there should not be any kernel module built.
>>
>> [YOCTO #7884]
>>
>> Signed-off-by: Saul Wold <sgw@linux.intel.com>
>> ---
>>   meta/classes/image.bbclass | 2 +-
>>   1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
>> index 01f8b3f..be245e9 100644
>> --- a/meta/classes/image.bbclass
>> +++ b/meta/classes/image.bbclass
>> @@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
>>   EXCLUDE_FROM_WORLD = "1"
>>
>>   USE_DEVFS ?= "1"
>> -USE_DEPMOD ?= "1"
>> +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'
>>
>
> I'm not convinced this is the right way to solve this. How about we
> teach the code in rootfs.py not to generate a modules.dep file if there
> are no kernel modules to generate dependency information for?
>
I guess we could check for /lib/modules, but I think checking for 
virtual/kernel is cleaner and safer since we know we don't want to run 
this for linux-dummy, but if some random recipe happens to create 
/lib/modules it will break.

Unless you has some other check in mind to verify no modules are created

I also thought about a change to linux-dummy to place an 
kernel-abiversion, but that had other dangers.

Sau!

> Cheers,
>
> Richard
>

Re: [PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[Richard Purdie]

On Tue, 2015-06-23 at 15:44 -0700, Saul Wold wrote:
> On 06/23/2015 02:53 PM, Richard Purdie wrote:
> > On Tue, 2015-06-23 at 12:22 -0700, Saul Wold wrote:
> >> The image bbclass will try to find the kernel-abiversion file which is not part
> >> of the linux-dummy kernel since there is no actual kernel. In this case using
> >> depmod also does not make sense since there should not be any kernel module built.
> >>
> >> [YOCTO #7884]
> >>
> >> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> >> ---
> >>   meta/classes/image.bbclass | 2 +-
> >>   1 file changed, 1 insertion(+), 1 deletion(-)
> >>
> >> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> >> index 01f8b3f..be245e9 100644
> >> --- a/meta/classes/image.bbclass
> >> +++ b/meta/classes/image.bbclass
> >> @@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
> >>   EXCLUDE_FROM_WORLD = "1"
> >>
> >>   USE_DEVFS ?= "1"
> >> -USE_DEPMOD ?= "1"
> >> +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}'
> >>
> >
> > I'm not convinced this is the right way to solve this. How about we
> > teach the code in rootfs.py not to generate a modules.dep file if there
> > are no kernel modules to generate dependency information for?
> >
> I guess we could check for /lib/modules, but I think checking for 
> virtual/kernel is cleaner and safer since we know we don't want to run 
> this for linux-dummy, but if some random recipe happens to create 
> /lib/modules it will break.
> 
> Unless you has some other check in mind to verify no modules are created

Something like "find -name *.ko" on /lib/modules was what I was
wondering about. Extrapolating, perhaps this code should iterate any
version directories here in case multiple sets of modules for different
kernel versions were installed? That way it wouldn't need to know about
the kernel-abiversion file?

> I also thought about a change to linux-dummy to place an 
> kernel-abiversion, but that had other dangers.

Right. Unfortunately this file is used to populate KERNEL_VERSION
elsewhere and we may also have problems in those places with linux-dummy
too :/

Cheers,

Richard

Re: [PATCH][master&fido] image.bbclass: Disable USE_DEPMOD for the dummy kernel

[Khem Raj]

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


> On Jun 23, 2015, at 12:22 PM, Saul Wold <sgw@linux.intel.com> wrote:
> 
> The image bbclass will try to find the kernel-abiversion file which is not part
> of the linux-dummy kernel since there is no actual kernel. In this case using
> depmod also does not make sense since there should not be any kernel module built.
> 
> [YOCTO #7884]
> 
> Signed-off-by: Saul Wold <sgw@linux.intel.com>
> ---
> meta/classes/image.bbclass | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 01f8b3f..be245e9 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -66,7 +66,7 @@ PACKAGE_INSTALL_ATTEMPTONLY ?= "${FEATURE_INSTALL_OPTIONAL}"
> EXCLUDE_FROM_WORLD = "1"
> 
> USE_DEVFS ?= "1"
> -USE_DEPMOD ?= "1"
> +USE_DEPMOD ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", "linux-dummy", "0", "1", d)}’
> 

this is an abstraction, it should work on more general metadata then just OE-Core,
using hardcoded recipe names doesn't sound right here. Richard’s suggestion on
finding the .ko’s is generic, which should be the better and generic solution.


> PID = "${@os.getpid()}"
> 
> --
> 2.1.0
> 
> --
> _______________________________________________
> 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 --]