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
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 <[email protected]>:
> 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
>
On Thu, 2012-05-03 at 14:02 +0200, Jörg Otte wrote:
> 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"
There's a number of things I can think of for "EXPERIMENTAL function".
What exactly do you mean here?
> The question is whether this is guaranteed.
If you were thinking about usage of CONFIG_EXPERIMENTAL in code or in
Makefiles: no, I don't think there's a guarantee that this won't be
done. But it should be clear that EXPERIMENTAL is intended as, say, a
tag for config options. So it's likely that usage of EXPERIMENTAL
outside that scope will be prevented.
Paul Bolle
OK, thanks again Paul, for your answeres.
J?rg
2012/5/4 Paul Bolle <[email protected]>:
> On Thu, 2012-05-03 at 14:02 +0200, J?rg Otte wrote:
>> 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"
>
> There's a number of things I can think of for "EXPERIMENTAL function".
> What exactly do you mean here?
>
>> The question is whether this is guaranteed.
>
> If you were thinking about usage of CONFIG_EXPERIMENTAL in code or in
> Makefiles: no, I don't think there's a guarantee that this won't be
> done. But it should be clear that EXPERIMENTAL is intended as, say, a
> tag for config options. So it's likely that usage of EXPERIMENTAL
> outside that scope will be prevented.
>
>
> Paul Bolle
>