[OE-core] Is it necessary to fix the Bugzilla – Bug 11807 and 5876 ?

Bruce Ashfield bruce.ashfield at windriver.com
Thu Dec 6 21:48:36 UTC 2018


On 2018-12-05 10:33 p.m., Hongzhi, Song wrote:
> 
> 
> On 12/06/2018 11:04 AM, Hongzhi, Song wrote:
>>
>>
>> On 12/05/2018 06:57 PM, Bruce Ashfield wrote:
>>> On 12/5/18 5:17 AM, Hongzhi, Song wrote:
>>>> Hi all,
>>>>
>>>> I don't know if it is necessary to do this enhancement.
>>>>
>>>> 1. Bug 11807:
>>>>
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=11807
>>>>
>>>>
>>>> 'CONFIG_EXTRA_FIRMWARE' is used to be set to the names of firmware 
>>>> files which
>>>>
>>>> should be provided by driver vendors.
>>>>
>>>> 'CONFIG_EXTRA_FIRMWARE_DIR' is set to a path which contains above 
>>>> firmware
>>>>
>>>> files. The default path is /lib/firmware if the 
>>>> 'CONFIG_EXTRA_FIRMWARE_DIR' is not set.
>>>>
>>>>
>>>> The path and firmware files must exist in rootfs eventually.
>>>>
>>>>
>>>> 2. Bug 5876:
>>>>
>>>> https://bugzilla.yoctoproject.org/show_bug.cgi?id=5876
>>>>
>>>>
>>>> I think it mean that bbclass should check the state of menuconfig.
>>>>
>>>>
>>>> I don't know if is necessary to fix these bugs. Could you give me help?
>>>
>>> I have some enhancements and other things in flight that can already do
>>> what these two bugs are talking about. Paul and I had discussed some of
>>> the config auditing on the list about a year ago, and agreed that
>>> there's no sense duplicating the functionality that already exists
>>> (rather I was going to tweak a few things to make it more easily
>>> accessible).
>>>
>>> If you want, you could assign 5876 to me, and I could take care of it.
>>
>> Hi Bruce,
>>
>> Thanks, I will assign it to you.
>>
>>>
>>> As for 11807, that is simply a kernel configuration option and it should
>>> be handled like any other. I don't see the need for anything special to
>>> be done.
>>>
>>
>> This option is different from the common options. It can only be set 
>> two types
>> of value, "" and "filename1 filename2 ...", which depends on customer.
>>
>> Maybe we can add a variable containing useful firmware in kernel 
>> recipe for customer.
>> The variable will eventually set CONFIG_EXTRA_FIRMWARE in .config .
> 

I disagree that this is different from any other option, simply
because it is used for firmware or has filenames doesn't immediately
make it require special handling.

> How to translate the variable to CONFIG_EXTRA_FIRMWARE and set the 
> option in .config ?
> 1. Append do_kernel_configme in kernel recipe with sed command inside it.
> 2. or modify the bbclass.

This is exactly the problem. You don't want to have many parts
of the build system messing about and modifying the .config.

It makes debug difficult, and it makes the entire process more
complex. Not to mention, when doing things like this, you've now
made parts of the system sensitive to kernel versions, patched
kernels, etc, since you'd be trying to do this in a common location.
In fact, you wouldn't want to have someone setting the actual CONFIG_
value as it appears in the kernel, you'd want some abstracted variable
name that could be mapped to the options later.

In fact, that sort of mapping is what is done with the KERNEL_FEATURES
variable already. It is supposed to translate abstract groups of options
to their kernel specific values. Due to the way the kernel recipes work,
etc, that isn't globally true .. but that is the intent none the less.

The only place you really know about the option and the firmware is in
the kernel recipe anyway. In there you are already specifying a
defconfig or fragments, so it isn't that hard to insist that someone
set the firmware option and manage it in their kernel. It isn't
something that is done everywhere, so it still falls into a special
case.

Bruce

> 
> I am not sure if the requirement in the bug 11807 is reasonable and if 
> my above opinion is
> practical.
> 
> Thanks,
> --Hongzhi
> 
>>
>> --Hongzhi
>>
>>> Bruce
>>>
>>>
>>>>
>>>>
>>>> --Honghzi
>>>>
>>>>
>>>
>>>
>>
> 



More information about the Openembedded-core mailing list