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