On Fri, 29 Oct 2010 11:37:31 +1100 Stephen Rothwell <[email protected]> wrote:
>
> On Tue, 12 Oct 2010 15:19:46 +0200 Michal Marek <[email protected]> wrote:
> >
> > This reverts commit 71ebc01, which was a 2.6.36-only stopgap solution.
>
> I was hoping that we would have the number of these warnings down to
> something reasonable before this revert made it into Linus' tree ...
>
> I guess fixing the V4L stuff will become a bit more urgent, now :-)
Is there any chance that the V4L kconfig warnings will be fixed? It is
quite irritating for those of us who do allmodconfig (and allyesconfig)
builds ...
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
On Mon, 22 Nov 2010 11:48:01 +1100 Stephen Rothwell wrote:
> On Fri, 29 Oct 2010 11:37:31 +1100 Stephen Rothwell <[email protected]> wrote:
> >
> > On Tue, 12 Oct 2010 15:19:46 +0200 Michal Marek <[email protected]> wrote:
> > >
> > > This reverts commit 71ebc01, which was a 2.6.36-only stopgap solution.
> >
> > I was hoping that we would have the number of these warnings down to
> > something reasonable before this revert made it into Linus' tree ...
> >
> > I guess fixing the V4L stuff will become a bit more urgent, now :-)
>
> Is there any chance that the V4L kconfig warnings will be fixed? It is
> quite irritating for those of us who do allmodconfig (and allyesconfig)
> builds ...
Yes, the MEDIA kconfig warnings are irritating.
I just use "grep -v MEDIA" to ignore them. :)
I haven't seen any email from Michal for more than one week.
Hopefully he will be back soon.
There are patches from Arnaud Lacombe <[email protected]>
to introduce a VISIBLE property for kconfig symbols (this fixes the
MEDIA kconfig warnings), but Michal has not commented on them.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Hi,
On Sun, Nov 21, 2010 at 7:48 PM, Stephen Rothwell <[email protected]> wrote:
> On Fri, 29 Oct 2010 11:37:31 +1100 Stephen Rothwell <[email protected]> wrote:
>>
>> On Tue, 12 Oct 2010 15:19:46 +0200 Michal Marek <[email protected]> wrote:
>> >
>> > This reverts commit 71ebc01, which was a 2.6.36-only stopgap solution.
>>
>> I was hoping that we would have the number of these warnings down to
>> something reasonable before this revert made it into Linus' tree ...
>>
>> I guess fixing the V4L stuff will become a bit more urgent, now :-)
>
> Is there any chance that the V4L kconfig warnings will be fixed? ?It is
> quite irritating for those of us who do allmodconfig (and allyesconfig)
> builds ...
>
There is 2 patches which fixes that by adding to the kconfig language
a "visible" property to menus, 1 revert of "another" solution (which
works but does not scale) and 2 patch which makes usage of the new
property. Ack-ed and complemented by Mauro, but still waiting
review/blessing by Michal.
The core change is available here: https://patchwork.kernel.org/patch/306412/
Alternatively, if you don't care about the menu structure, Randy
proposed a one-liner.
- Arnaud
On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe wrote:
> Hi,
>
> On Sun, Nov 21, 2010 at 7:48 PM, Stephen Rothwell <[email protected]> wrote:
> > On Fri, 29 Oct 2010 11:37:31 +1100 Stephen Rothwell <[email protected]> wrote:
> >>
> >> On Tue, 12 Oct 2010 15:19:46 +0200 Michal Marek <[email protected]> wrote:
> >> >
> >> > This reverts commit 71ebc01, which was a 2.6.36-only stopgap solution.
> >>
> >> I was hoping that we would have the number of these warnings down to
> >> something reasonable before this revert made it into Linus' tree ...
> >>
> >> I guess fixing the V4L stuff will become a bit more urgent, now :-)
> >
> > Is there any chance that the V4L kconfig warnings will be fixed? ?It is
> > quite irritating for those of us who do allmodconfig (and allyesconfig)
> > builds ...
> >
> There is 2 patches which fixes that by adding to the kconfig language
> a "visible" property to menus, 1 revert of "another" solution (which
> works but does not scale) and 2 patch which makes usage of the new
> property. Ack-ed and complemented by Mauro, but still waiting
> review/blessing by Michal.
>
> The core change is available here: https://patchwork.kernel.org/patch/306412/
>
> Alternatively, if you don't care about the menu structure, Randy
> proposed a one-liner.
which Mauro nacked.
I don't care about the menu structure, I just want to eliminate the
warnings.
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
Hi,
On Sun, Nov 21, 2010 at 9:09 PM, Randy Dunlap <[email protected]> wrote:
> On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe wrote:
>> [..]
>> Alternatively, if you don't care about the menu structure, Randy
>> proposed a one-liner.
>
> which Mauro nacked.
>
> I don't care about the menu structure, I just want to eliminate the
> warnings.
>
Yes, I know. I just wanted to raise the point "if you don't care about
the menu structure, a oneliner can do the job".
- Arnaud
Hi,
On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe <[email protected]> wrote:
>
> There is 2 patches which fixes that by adding to the kconfig language
> a "visible" property to menus, 1 revert of "another" solution (which
> works but does not scale) and 2 patch which makes usage of the new
> property. Ack-ed and complemented by Mauro, but still waiting
> review/blessing by Michal.
>
> The core change is available here: https://patchwork.kernel.org/patch/306412/
>
> Alternatively, if you don't care about the menu structure, Randy
> proposed a one-liner.
OK, good to know it is being worked on. Thanks.
--
Cheers,
Stephen Rothwell [email protected]
http://www.canb.auug.org.au/~sfr/
Em 22-11-2010 00:57, Stephen Rothwell escreveu:
> Hi,
>
> On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe <[email protected]> wrote:
>>
>> There is 2 patches which fixes that by adding to the kconfig language
>> a "visible" property to menus, 1 revert of "another" solution (which
>> works but does not scale) and 2 patch which makes usage of the new
>> property. Ack-ed and complemented by Mauro, but still waiting
>> review/blessing by Michal.
>>
>> The core change is available here: https://patchwork.kernel.org/patch/306412/
>>
>> Alternatively, if you don't care about the menu structure, Randy
>> proposed a one-liner.
>
> OK, good to know it is being worked on. Thanks.
>
I added a branch on my tree with Arnaud patches and my additional patch, at:
http://git.kernel.org/?p=linux/kernel/git/mchehab/linux-next.git;a=shortlog;h=refs/heads/kconfig_fixes
This way, we avoid loosing the patches, and people might use it to remove those warnings.
Cheers,
Mauro
PS.: I don't intend to merge them on my master branch, as the proper way is to submit it
to 2.6.37 via Michal's tree. Also, it will may cause conflicts on linux-next, due to the
bison-generated files.
Hi,
On Sun, Nov 21, 2010 at 9:57 PM, Stephen Rothwell <[email protected]> wrote:
> Hi,
>
> On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe <[email protected]> wrote:
>>
>> There is 2 patches which fixes that by adding to the kconfig language
>> a "visible" property to menus, 1 revert of "another" solution (which
>> works but does not scale) and 2 patch which makes usage of the new
>> property. Ack-ed and complemented by Mauro, but still waiting
>> review/blessing by Michal.
>>
>> The core change is available here: https://patchwork.kernel.org/patch/306412/
>>
>> Alternatively, if you don't care about the menu structure, Randy
>> proposed a one-liner.
>
> OK, good to know it is being worked on. ?Thanks.
>
FYI, I withdrawn the patches and ask for them not to be merged[0], as
there is a clear lack of interest to see this issue resolved.
Mauro, may I ask you to remove my patches from:
git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git
kconfig_fixes
please ?
Thanks,
- Arnaud
[0]: cf. Message-id
<[email protected]> on
linux-kbuild@
On 25 November 2010 17:16, Arnaud Lacombe <[email protected]> wrote:
> On Sun, Nov 21, 2010 at 9:57 PM, Stephen Rothwell <[email protected]> wrote:
>> On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe <[email protected]> wrote:
>>> There is 2 patches which fixes that by adding to the kconfig language
>>> a "visible" property to menus, 1 revert of "another" solution (which
>>> works but does not scale) and 2 patch which makes usage of the new
>>> property. Ack-ed and complemented by Mauro, but still waiting
>>> review/blessing by Michal.
>>>
>>> The core change is available here: https://patchwork.kernel.org/patch/306412/
>>>
>>> Alternatively, if you don't care about the menu structure, Randy
>>> proposed a one-liner.
>>
>> OK, good to know it is being worked on. Thanks.
>>
> FYI, I withdrawn the patches and ask for them not to be merged[0], as
> there is a clear lack of interest to see this issue resolved.
>
> Mauro, may I ask you to remove my patches from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git
> kconfig_fixes
I still think the patches are useful. The fact that you didn't get any
comments from Michal doesn't mean that they are a bad idea, just lack
of time on the kbuild maintainer's side. It may have been a better
idea to cc LKML as well when you posted them (I for one don't follow
the kbuild list).
As for waiting times, I had patches taking even two years to get
merged. And my kbuild patch which actually introduced such warnings
had been around for nearly a year.
Now, commenting on your patches, you added a new statement, 'visible
if...' for menus. Can we not change it to something like:
-menu "I2C Algorithms"
- depends on !I2C_HELPER_AUTO
+menu "I2C Algorithms" if !I2C_HELPER_AUTO
--
Catalin
Hi,
On Thu, Nov 25, 2010 at 12:43 PM, Catalin Marinas
<[email protected]> wrote:
> Now, commenting on your patches, you added a new statement, 'visible
> if...' for menus. Can we not change it to something like:
>
> -menu "I2C Algorithms"
> - ? ? ? depends on !I2C_HELPER_AUTO
> +menu "I2C Algorithms" if !I2C_HELPER_AUTO
>
no because if_expr are translated internally in term of dependency,
which we don't want.
- Arnaud
Em 25-11-2010 15:16, Arnaud Lacombe escreveu:
> Hi,
>
> On Sun, Nov 21, 2010 at 9:57 PM, Stephen Rothwell <[email protected]> wrote:
>> Hi,
>>
>> On Sun, 21 Nov 2010 20:58:54 -0500 Arnaud Lacombe <[email protected]> wrote:
>>>
>>> There is 2 patches which fixes that by adding to the kconfig language
>>> a "visible" property to menus, 1 revert of "another" solution (which
>>> works but does not scale) and 2 patch which makes usage of the new
>>> property. Ack-ed and complemented by Mauro, but still waiting
>>> review/blessing by Michal.
>>>
>>> The core change is available here: https://patchwork.kernel.org/patch/306412/
>>>
>>> Alternatively, if you don't care about the menu structure, Randy
>>> proposed a one-liner.
>>
>> OK, good to know it is being worked on. Thanks.
>>
> FYI, I withdrawn the patches and ask for them not to be merged[0], as
> there is a clear lack of interest to see this issue resolved.
>
> Mauro, may I ask you to remove my patches from:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-next.git
> kconfig_fixes
>
> please ?
I prefer to have them there, while the issue remains at .37/-next builds.
It is a pain to see all those warnings polluting my console, every time
I recompile things, and I can't simply do a grep to discard MEDIA
warnings/errors (as someone proposed), as this may prevent me to get real
errors at media builds.
The better is to give more time to Marek/Sam to review your patch
series and ack or, if they don't agree, to send an alternative patchset
to fix the issues or to revert the changeset that started to produce
those troubles.
Cheers,
Mauro
On 25 November 2010 18:09, Arnaud Lacombe <[email protected]> wrote:
> On Thu, Nov 25, 2010 at 12:43 PM, Catalin Marinas
> <[email protected]> wrote:
>> Now, commenting on your patches, you added a new statement, 'visible
>> if...' for menus. Can we not change it to something like:
>>
>> -menu "I2C Algorithms"
>> - depends on !I2C_HELPER_AUTO
>> +menu "I2C Algorithms" if !I2C_HELPER_AUTO
>>
> no because if_expr are translated internally in term of dependency,
> which we don't want.
That's correct but I was wondering whether we could change this kind
of 'if' to a visibility attribute or a weaker dependency and avoid
'select' warnings. This way we wouldn't introduce new keywords to the
kconfig language.
--
Catalin
On 26.11.2010 13:33, Catalin Marinas wrote:
> On 25 November 2010 18:09, Arnaud Lacombe <[email protected]> wrote:
>> On Thu, Nov 25, 2010 at 12:43 PM, Catalin Marinas
>> <[email protected]> wrote:
>>> Now, commenting on your patches, you added a new statement, 'visible
>>> if...' for menus. Can we not change it to something like:
>>>
>>> -menu "I2C Algorithms"
>>> - depends on !I2C_HELPER_AUTO
>>> +menu "I2C Algorithms" if !I2C_HELPER_AUTO
>>>
>> no because if_expr are translated internally in term of dependency,
>> which we don't want.
>
> That's correct but I was wondering whether we could change this kind
> of 'if' to a visibility attribute or a weaker dependency and avoid
> 'select' warnings. This way we wouldn't introduce new keywords to the
> kconfig language.
I quite like the "visible if" notation because it makes it explicit that
it only affects the display of the menu and does not add any dependency
to the data.
Michal
On 26 November 2010 13:33, Michal Marek <[email protected]> wrote:
> On 26.11.2010 13:33, Catalin Marinas wrote:
>> On 25 November 2010 18:09, Arnaud Lacombe <[email protected]> wrote:
>>> On Thu, Nov 25, 2010 at 12:43 PM, Catalin Marinas
>>> <[email protected]> wrote:
>>>> Now, commenting on your patches, you added a new statement, 'visible
>>>> if...' for menus. Can we not change it to something like:
>>>>
>>>> -menu "I2C Algorithms"
>>>> - depends on !I2C_HELPER_AUTO
>>>> +menu "I2C Algorithms" if !I2C_HELPER_AUTO
>>>>
>>> no because if_expr are translated internally in term of dependency,
>>> which we don't want.
>>
>> That's correct but I was wondering whether we could change this kind
>> of 'if' to a visibility attribute or a weaker dependency and avoid
>> 'select' warnings. This way we wouldn't introduce new keywords to the
>> kconfig language.
>
> I quite like the "visible if" notation because it makes it explicit that
> it only affects the display of the menu and does not add any dependency
> to the data.
That's fine by me. If you like this feature then it could get upstream :)
--
Catalin