All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bruce Ashfield <bruce.ashfield@windriver.com>
To: "Hongzhi, Song" <hongzhi.song@windriver.com>
Cc: oe-core <openembedded-core@lists.openembedded.org>
Subject: Re: Is it necessary to fix the Bugzilla – Bug 11807 and 5876 ?
Date: Thu, 6 Dec 2018 16:48:36 -0500	[thread overview]
Message-ID: <be00d0a1-e2a4-cbb6-5037-a4ef7bb51e47@windriver.com> (raw)
In-Reply-To: <e321e6c6-40e4-ecda-c738-5d6784beefee@windriver.com>

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
>>>>
>>>>
>>>
>>>
>>
> 



      reply	other threads:[~2018-12-06 21:48 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-05 10:17 Is it necessary to fix the Bugzilla – Bug 11807 and 5876 ? Hongzhi, Song
2018-12-05 10:57 ` Bruce Ashfield
2018-12-06  3:04   ` Hongzhi, Song
2018-12-06  3:33     ` Hongzhi, Song
2018-12-06 21:48       ` Bruce Ashfield [this message]

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=be00d0a1-e2a4-cbb6-5037-a4ef7bb51e47@windriver.com \
    --to=bruce.ashfield@windriver.com \
    --cc=hongzhi.song@windriver.com \
    --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.