Re: [PATCH 0/8] drm, fbdev: rework dependencies

From: Jani Nikula <jani.nikula@linux.intel.com>
To: Jason Gunthorpe <jgg@ziepe.ca>, Daniel Vetter <daniel@ffwll.ch>
Cc: Arnd Bergmann <arnd@arndb.de>,
	dri-devel@lists.freedesktop.org, linux-fbdev@vger.kernel.org,
	Nicolas Pitre <nico@fluxnic.net>,
	Andrzej Hajda <a.hajda@samsung.com>,
	Saeed Mahameed <saeedm@mellanox.com>,
	masahiroy@kernel.org, Laurent.pinchart@ideasonboard.com,
	linux-renesas-soc@vger.kernel.org,
	kieran.bingham+renesas@ideasonboard.com, airlied@linux.ie,
	daniel@zonque.org, haojian.zhuang@gmail.com,
	robert.jarzmik@free.fr, marex@denx.de, stefan@agner.ch,
	linux-graphics-maintainer@vmware.com, thellstrom@vmware.com,
	jfrederich@gmail.com, dsd@laptop.org, geert@linux-m68k.org
Subject: Re: [PATCH 0/8] drm, fbdev: rework dependencies
Date: Mon, 20 Apr 2020 11:14:02 +0300	[thread overview]
Message-ID: <87y2qq1smt.fsf@intel.com> (raw)
In-Reply-To: <20200417190854.GI26002@ziepe.ca>

On Fri, 17 Apr 2020, Jason Gunthorpe <jgg@ziepe.ca> wrote:
> On Fri, Apr 17, 2020 at 07:14:53PM +0200, Daniel Vetter wrote:
>> On Fri, Apr 17, 2020 at 05:55:45PM +0200, Arnd Bergmann wrote:
>> > I tried to fix up some dependencies after the sii8620 "imply EXTCON"
>> > statementn broke, trying a few things but in the backing out a
>> > change that would completely reverse the LEDS_CLASS selects into
>> > a 'depends on'. 
>> > 
>> > However, what I got now are multiple changes that remove gratious
>> > "selects" that lead to circular dependencies for sii8620 and others:
>> > 
>> > - Anything doing "select FB" is now gone, or becomes "depends on FB",
>> > 
>> > - DDC support depends on I2C instead of selecting it
>> > 
>> > - backlight class device support is never selected by framebuffer
>> >   drivers but has proper dependencies
>> > 
>> > I have done thousands of randconfig build tests on this, but no
>> > runtime tests.
>> > 
>> > Some of the 'depends on FOO || !FOO' statements could be simplified
>> > into a new 'uses FOO' syntax based on a patch from Saeed Mahameed,
>> > but I would for the moment treat that as a cleanup that can be done
>> > later.
>> > 
>> > If we can agree on these changes, maybe someone can merge them
>> > through the drm-misc tree.
>> > 
>> > Please review
>> 
>> Biggest concern I have is that usability of make menuconfig is horrible,
>> and it's very hard to find options that are hidden by depends on. You can
>> use the search interface, if you happen to know the option.
>> 
>> Once you've surmounted that bar, the next one is trying to find what
>> exactly you need to enable. Which again means endless of recursive
>> screaming at Kconfig files, since make menuconfig doesn't help you at all.
>
> +1 on this. But this is a general kconfig problem, and not unique to
> DRM, I've done this screaming for many different things now.. eg to
> turn on every single RDMA driver.
>
> I hackily delt with it by creating this rather insane script based on
> the python kconfiglib to try and sort things out mostly automatically:
>
> https://github.com/jgunthorpe/Kernel-Maintainer-Tools/blob/master/gj_tools/cmd_kconfig.py
>
> It would be great if menuconfig had a key to say 'hey, really, turn
> this on and everything it depends on, recursively'

I'm really all for switching to using depends when that is the
semantically right thing to do. In many places using select is a hack to
make the UI simpler, and that's just plain wrong. We'll be doomed to
perpetual randconfig build failures and duct tape fixes.

I'm pretty tired of this, and I regularly ignore those duct tape fixes
to i915 backlight build issues on some bizarre configs that nobody will
ever use, and would not exist if depends were used throughout.

I'm fine with select but only when it's restricted to symbols that have
no dependencies of their own and have no UI. This is in line with
Documentation/kbuild/kconfig-language.rst. Not enforcing this is another
Kconfig tool shortcoming.