Message-ID: <20150406112743.40d5b5cf@recife.lan>
Date:	Mon, 6 Apr 2015 11:27:43 -0300
From:	Mauro Carvalho Chehab <mchehab@....samsung.com>
To:	Paul Bolle <pebolle@...cali.nl>
Cc:	Jani Nikula <jani.nikula@...ux.intel.com>,
	Gerd Hoffmann <kraxel@...hat.com>,
	dri-devel@...ts.freedesktop.org, virtio-dev@...ts.oasis-open.org,
	mst@...hat.com, open list <linux-kernel@...r.kernel.org>,
	airlied@...hat.com,
	"open list:MEDIA INPUT INFRA..." <linux-media@...r.kernel.org>
Subject: Re: [PATCH v2 1/4] break kconfig dependency loop

Em Mon, 06 Apr 2015 11:50:21 +0200
Paul Bolle <pebolle@...cali.nl> escreveu:

> On Wed, 2015-04-01 at 16:47 +0300, Jani Nikula wrote:
> > I think part of the problem is that "select" is often used not as
> > documented [1] but rather as "show my config in menuconfig for
> > convenience even if my dependency is not met, and select the dependency
> > even though I know it can screw up the dependency chain".
> 
> Perhaps people use select because it offers, given the problem they
> face, a reasonable way to make the kconfig tools generate a
> sensible .config. It helps them to spend less time fiddling with Kconfig
> files. And they expect that it helps others to configure their build
> more easily, as it might save those others some work.

At least on media, the main usage of select is to handle complex hardware
where lots of drivers are needed in order to have support for all
boards supported by a given board.

On a practical example, let's take a look at em28xx driver. This is a
bridge driver for media boards. It supports ~100 different boards.
Each board may have different tuners, different analog TV demods,
different digital TV demods, eeproms attached into one of its I2C buses.

As this is an USB stick, the normal user will never know what are the
other components of the board without some hard work (by opening the USB
stick by seeking for the information at the Internet until he discovers
all the components).

Even after knowing the hardware components, he has to figure out what
drivers implement support for each component.

So, for the normal user, we offer a way for the user to select all
possible combinations via MEDIA_SUBDRV_AUTOSELECT. This way, he'll know
for sure that all boards supported by em28xx will be available.

For those that would embedded em28xx on some hardware (like a TV
PVR box), he can disable such option and manually select the specific
components his hardware uses.

For obvious reasons, we recommend distros to always enable
MEDIA_SUBDRV_AUTOSELECT.

So, yes, select saves a lot of work to configure the build what they
want on an easy and sane way.

That's said, while it would be possible to convert select into
depends on, the result would be really ugly, and very hard to be
maintained, as I2C drivers that don't actually depend on the bridge
drivers would need a fake depends on list:

config DVB_MB86A20S
	tristate "Fujitsu mb86a20s"
	# real dependency chain
	depends on DVB_CORE && I2C
	# fake dependency chain
	depends on (!MEDIA_SUBDRV_AUTOSELECT || CONFIG_VIDEO_CX23885_DVB || CONFIG_VIDEO_CX231XX_DVB || CONFIG_VIDEO_EM28xx_DVB)

I got here an easy example of an ISDB-T driver, with is not used on
many boards. There are other I2C drivers that are used by almost all
media drivers, with would result on a very complex fake dependency chain.

The worse thing with such ugly fake dependency chain is that people adding
a new driver (or support for a new board) would need to remember to dig
into drivers that weren't touched, adding new stuff on their Kconfig.

> > In the big picture, it feels like menuconfig needs a way to display
> > items whose dependencies are not met, and a way to recursively enable
> > said items and all their dependencies when told.

I believe so.

> How could that work its way through (multiple levels of) things like:
>     depends on FOO || (BAZ && BAR)

At least for our typical use case, the dependency chain should not have
things like the above, as we use this mainly for I2C drivers, and the
bridge drivers also depend on I2C.

I would say that, if Kconfig adds a recursive select implementation, such
implementation should:

- stop recursion if the depends condition was met;
- if the depends condition is unmet and has two or more possible options
  to satisfy (like on your above example), it should prompt the user about
  what option it would want. If it can't do it (for example, for a "silent"
  type of config, where it shouldn't be expected any userspace interaction),
  it should print a warning and not enable the driver.

Granted, this is easier said than done. We have this problem mapped
for a long time, but none was brave enough (or had enough time) to
actually try to implement something like that. So, what we generally
do, as a workaround, is to try to simplify the Kconfig stuff to avoid
complex use cases. We do that by adding fake dependencies to drivers
that might require another driver for some board to work. For example,
several USB media drivers now depends on I2C_MUX just because a few of
the possible drivers it may need should select I2C_MUX.

Btw, I2C_MUX is an optional feature of the I2C core. There's no way
for a normal user to know if a driver would need such feature or not,
as it basically depends on how the device was internally wired and if
the Kernel driver would use it (older drivers have their own solution
without using the I2C_MUX new way).

There are a few other such options at the I2C sub-system. All of them
depends on I2C only (with is a mandatory option for any I2C driver),
so select works fine for such features.

> 
> > This would reduce the
> > resistance to sticking with "select" when clearly "depends" is what's
> > meant.
> 
> I had drafted a rather verbose response to this. But I think I'm not
> really sure what you're saying here, probably because "select" and
> "depends on" are rather different. How would you know that the actual
> intention was to use "depends on"?
> 
> 
> Paul Bolle

Regards,
Mauro
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists