Received-SPF: pass (google.com: domain of linux-kernel+bounces-153763-linux.lists.archive=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99;
Precedence: bulk
MIME-Version: 1.0
References: <cover.1713780345.git.geert+renesas@glider.be> <87il09ty4u.fsf@intel.com>
 <ff4f9e8f-0825-4421-adf9-e3914b108da7@app.fastmail.com> <875xw9ttl6.fsf@intel.com>
 <af6e26d1-1402-4ed2-a650-b58eae77273e@app.fastmail.com>
In-Reply-To: <af6e26d1-1402-4ed2-a650-b58eae77273e@app.fastmail.com>
From: Geert Uytterhoeven <geert@linux-m68k.org>
Date: Mon, 22 Apr 2024 18:58:21 +0200
Message-ID: <CAMuHMdXCL-gbKr6mUBPWONtRjz=X0vZQgiS=02WXXSFf67yBww@mail.gmail.com>
Subject: Re: [PATCH 00/11] drm: Restore helper usability
To: Arnd Bergmann <arnd@arndb.de>
Cc: Jani Nikula <jani.nikula@linux.intel.com>, 
	Geert Uytterhoeven <geert+renesas@glider.be>, 
	Maarten Lankhorst <maarten.lankhorst@linux.intel.com>, Maxime Ripard <mripard@kernel.org>, 
	Thomas Zimmermann <tzimmermann@suse.de>, Dave Airlie <airlied@gmail.com>, Daniel Vetter <daniel@ffwll.ch>, 
	dri-devel@lists.freedesktop.org, linux-kernel@vger.kernel.org, 
	Linux-Renesas <linux-renesas-soc@vger.kernel.org>, Masahiro Yamada <masahiroy@kernel.org>, 
	linux-kbuild <linux-kbuild@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Arnd,

CC kbuild

On Mon, Apr 22, 2024 at 3:55=E2=80=AFPM Arnd Bergmann <arnd@arndb.de> wrote=
:
> On Mon, Apr 22, 2024, at 15:28, Jani Nikula wrote:
> > On Mon, 22 Apr 2024, "Arnd Bergmann" <arnd@arndb.de> wrote:
> >> 2. Using "select" on user visible symbols that have dependencies
> >>    is a common source for bugs, and this is is a problem in
> >>    drivers/gpu/drm more than elsewhere in the kernel, as these
> >>    drivers traditionally select entire subsystems or drivers
> >>    (I2C, VIRTIO, INPUT, ACPI_WMI, BACKLIGHT_CLASS_DEVICE,
> >>    POWER_SUPPLY, SND_PCM, INTERCONNECT, ...). This regularly
> >>    leads to circular dependencies and we should fix all of them.
> >
> > What annoys me is that the fixes tend to fall in two categories:
> >
> > - Play catch with selecting the dependencies of the selected
> >   symbols. "depends on" handles this recursively, while select does
> >   not.
>
> I'm not sure where this misunderstanding comes from, as you
> seem to be repeating the same incorrect assumption about
> how select works that Maxime wrote in his changelog. To clarify,
> this works exactly as one would expect:
>
> config HELPER_A
>        tristate
>
> config HELPER_B
>        tristate
>        select HELPER_A
>
> config DRIVER
>        tristate "Turn on the driver and the helpers it uses"
>        select HELPER_B # this recursively selects HELPER_A
>
> Whereas this one is broken:
>
> config FEATURE_A
>        tristate "user visible if I2C is enabled"
>        depends on I2C
>
> config HELPER_B
>        tristate # hidden
>        select FEATURE_A
>
> config DRIVER
>        tristate "This driver is broken if I2C is disabled"
>        select HELPER_B

So the DRIVER section should gain a "depends on I2C" statement.

Yamada-san: would it be difficult to modify Kconfig to ignore symbols
like DRIVER that select other symbols with unmet dependencies?
Currently it already warns about that.

Handling this implicitly (instead of the current explict "depends
on") would have the disadvantage though: a user who is not aware of
the implicit dependency may wonder why DRIVER is invisible in his
config interface.

>
> >   There is no end to this, it just goes on and on, as the
> >   dependencies of the selected symbols change over time. Often the
> >   selects require unintuitive if patterns that are about the
> >   implementation details of the symbol being selected.
>
> Agreed, that is the problem I frequently face with drivers/gpu/drm,
> and most of the time it can only be solved by rewriting the whole
> system to not select user-visible symbol at all.

Gr{oetje,eeting}s,

                        Geert

--=20
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k=
org

In personal conversations with technical people, I call myself a hacker. Bu=
t
when I'm talking to journalists I just say "programmer" or something like t=
hat.
                                -- Linus Torvalds