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: <CADDKRnA7XMczevE2JRsMR508mdz+Rgs+QvV4QCMqnts8t+1y3A@mail.gmail.com>
Date:	Thu, 3 May 2012 14:02:45 +0200
From:	Jörg Otte <jrg.otte@...glemail.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Dave Airlie <airlied@...hat.com>, linux-kernel@...r.kernel.org
Subject: Re: [v3.4-rc5]: drm references experimental

Thanks,

> I also noticed that there's not a single instance of CONFIG_EXPERIMENTAL
> in any code-file or in any Makefile. EXPERIMENTAL is only relevant in,
> well, Kconfig space.

this means especially the following is not possible or does not occure:

NON-EXP:
driver "A" uses library function "B"

EXP:
unchanged driver "A" now uses EXPERIMENTAL function "B-EXP"

The question is whether this is guaranteed.

Thanks,Jörg


2012/5/2 Paul Bolle <pebolle@...cali.nl>:
> On Mon, 2012-04-30 at 16:31 +0200, Jörg Otte wrote:
>> there is a dependency between drm and experimental driver. If I
>> don't enable EXPERIMENTAL I see the following during configuration:
>>
>> warning: (DRM) selects DMA_SHARED_BUFFER which has unmet direct
>> dependencies (EXPERIMENTAL)
>>
>> I think non-experimental code shouldn't depend on experimental code.
>
> This reminds me of a brief discussion on the merits of EXPERIMENTAL
> starting at https://lkml.org/lkml/2012/1/18/385 . My impression from
> that discussion was that EXPERIMENTAL currently is set in most
> configurations (eg, even Debian stable has EXPERIMENTAL set). This means
> that people generally won't notice that an option that itself doesn't
> depend (indirectly) on EXPERIMENTAL selects an option that does depend
> directly on EXPERIMENTAL. So, yes, one wouldn't expect non-EXPERIMENTAL
> code to use EXPERIMENTAL code but, apparently, in practice it does.
>
> I also noticed that there's not a single instance of CONFIG_EXPERIMENTAL
> in any code-file or in any Makefile. EXPERIMENTAL is only relevant in,
> well, Kconfig space. That should make it somewhat less likely that there
> are surprising changes to the code than in other cases of options
> selecting options with unmet direct dependencies.
>
>
> Paul Bolle
>
--
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