[PATCH] drm/i915: Fix selecting CONFIG_DRM_KUNIT_TEST in debug builds
Jani Nikula
jani.nikula at linux.intel.com
Mon Jul 28 11:44:42 UTC 2025
On Thu, 24 Jul 2025, Imre Deak <imre.deak at intel.com> wrote:
> On Thu, Jul 24, 2025 at 05:31:28PM +0100, Ruben Wauters wrote:
>> On Thu, 2025-07-24 at 12:26 -0400, Rodrigo Vivi wrote:
>> > On Thu, Jul 24, 2025 at 12:02:37PM +0300, Imre Deak wrote:
>> > > Selecting an option which depends on other options only works if
>> > > the
>> > > dependencies are guaranteed to be selected (as these dependencies
>> > > will
>> > > not be automatically selected). CONFIG_DRM_KUNIT_TEST depends on
>> > > DRM,
>> > > MMU and KUNIT the first two of which are guaranteed to be selected
>> > > for
>> > > i915, but the last one is not. Hence, selecting
>> > > CONFIG_DRM_KUNIT_TEST in
>> > > i915 debug builds may result in CONFIG_DRM_KUNIT_TEST being
>> > > selected
>> > > without the CONFIG_KUNIT dependency being selected. This causes at
>> > > least
>> > > the following compile error:
>> > >
>> my bad, I guess I fundamentally misunderstood how the Kconfig system
>> worked, and assumed that if you selected one all the dependencies were
>> automatically selected. I guess this passed me by in testing cause I
>> already had CONFIG_KUNIT selected and didn't think to de-select it,
>> apologies.
>
> IME, it's easy to get the Kconfig dependency semantics wrong. Unless I
> get it wrong, 'depends on' will never select the options listed after
> it, it only determines if its parent option is visible during manual
> selection (and similarly if it's valid to select the same parent option
> from an other option automatically with 'select'). Maybe 'depends on' is
> a misnomer and 'visible if' or 'available if' would better describe its
> purpose.
The problem with "select" is that it will force the symbol to a value
without meeting the dependencies recursively the same way "depends on"
does.
Per kconfig-language.rst, "In general use select only for non-visible
symbols (no prompts anywhere) and for symbols with no dependencies."
BR,
Jani.
--
Jani Nikula, Intel
More information about the Intel-gfx
mailing list