Messages in this thread | | | Date | Thu, 3 May 2012 14:02:45 +0200 | Subject | Re: [v3.4-rc5]: drm references experimental | From | Jörg Otte <> |
| |
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@tiscali.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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |