lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <AANLkTi=Eb8k6gmeGqvC=Zbo2mj51oHcbCncZGt00u9Tx@mail.gmail.com>
Date:	Thu, 4 Nov 2010 00:15:13 -0400
From:	Arnaud Lacombe <lacombar@...il.com>
To:	Mauro Carvalho Chehab <mchehab@...hat.com>
Cc:	Michal Marek <mmarek@...e.cz>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	kyle@...hat.com, linux-kbuild@...r.kernel.org,
	linux-kernel@...r.kernel.org,
	Linux Media Mailing List <linux-media@...r.kernel.org>
Subject: Re: REGRESSION: Re: [GIT] kconfig rc fixes

Hi,

On Wed, Nov 3, 2010 at 11:19 PM, Mauro Carvalho Chehab
<mchehab@...hat.com> wrote:
> Em 03-11-2010 22:31, Arnaud Lacombe escreveu:
>> Hi,
>>
>> On Wed, Nov 3, 2010 at 6:29 PM, Mauro Carvalho Chehab
>> <mchehab@...hat.com> wrote:
>>> Em 09-10-2010 18:40, Michal Marek escreveu:
>>>>
>>>> Arnaud Lacombe (1):
>>>>       kconfig: delay symbol direct dependency initialization
>>>
>>> This patch generated a regression with V4L build. After applying it,
>>> some Kconfig dependencies that used to work with V4L Kconfig broke.
>>>
>> of course, but they were all-likely buggy. If a compiler version N
>> outputs a new legitimate warning because of a bug in the code, you do
>> not switch back to the previous version because the warning wasn't
>> there, you fix the code.
>>
>> That said, please point me to a false positive, eventually with a
>> minimal testcase, and I'll be happy to fix the issue.
>
> Arnaud,
>
> In the case of V4L and DVB drivers, what happens is that the same
> USB (or PCI) bridge driver can be attached to lots of
> different chipsets that do analog/digital/audio decoding/encoding.
>
> A normal user won't need to open his USB TV stick just to see TV on it.
> It just needs to select a bridge driver, and all possible options for encoders
> and decoders are auto-selected.
>
> If you're an advanced user (or are developing an embedded hardware), you
> know exactly what are the components inside the board/stick. So, the
> Kconfig allows to disable the automatic auto-selection, doing manual
> selection.
>
> The logic basically implements it, using Kconfig way, on a logic like:
>
>        auto = ask_user_if_ancillary_drivers_should_be_auto_selected();
>        driver_foo = ask_user_if_driver_foo_should_be_selected();
>        if (driver_foo && auto) {
>                select(bar1);
>                select(bar2);
>                select(bar3);
>                select(bar4);
>        }
> ...
>        if (!auto) {
>                open_menu()
>                ask_user_if_bar1_should_be_selected();
>                ask_user_if_bar2_should_be_selected();
>                ask_user_if_bar3_should_be_selected();
>                ask_user_if_bar4_should_be_selected();
> ...
>                close_menu()
>        }
>
no, you are hijacking Kconfig for something "illegal". Note that this
last word is not mine, it is the word used in the language
description:

  Note:
        select should be used with care. select will force
        a symbol to a value without visiting the dependencies.
        By abusing select you are able to select a symbol FOO even
        if FOO depends on BAR that is not set.
        In general use select only for non-visible symbols
        (no prompts anywhere) and for symbols with no dependencies.
        That will limit the usefulness but on the other hand avoid
        the illegal configurations all over.
        kconfig should one day warn about such things.

I guess the last line will need to be dropped, as this day has come.

 - Arnaud
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ