Linux Virtualization - Oct 2016 - [PATCH v9 17/19] drm/virtio: kconfig: Fix recursive dependency issue.

Hi Jani,

Sorry for the delay, I've been travelling last week.

On Tue, 20 Sep 2016, Jani Nikula wrote:
> On Tue, 20 Sep 2016, Peter Griffin <peter.griffin at linaro.org>
wrote:
> > Hi Emil,
> >
> > On Tue, 20 Sep 2016, Emil Velikov wrote:
> >
> >> On 5 September 2016 at 14:16, Peter Griffin <peter.griffin at
linaro.org> wrote:
> >> > ST_SLIM_REMOTEPROC must select REMOTEPROC, which exposes the
following
> >> > recursive dependency.
> >
> >
> >> >
> >> From a humble skim through remoteproc, drm and a few other
subsystems
> >> I think the above is wrong. All the drivers (outside of
remoteproc),
> >> that I've seen, depend on the core component, they don't
select it.
> >
> > I will let Bjorn comment on the remoteproc subsystem Kconfig design,
and
> > why it is like it is.
> >
> > For this particular SLIM_RPROC I have added it to Kconfig in keeping
with all
> > the other drivers in the remoteproc subsystem which has exposed this
recursive
> > dependency issue.
> >
> > For this particular kconfig symbol a quick grep reveals more drivers
in
> > the kernel using 'select', than 'depend on'
> >
> > git grep "select VIRTIO" | wc -l
> > 14
> >
> > git grep "depends on VIRTIO" | wc -l
> > 10
> >
> >
> >> Furthermore most places explicitly hide the drivers from the menu
if
> >> the core component isn't enabled.
> >
> > Remoteproc subsystem takes a different approach, the core code is only
enabled
> > if a driver which relies on it is enabled. This IMHO makes sense, as
> > remoteproc is not widely used (only a few particular ARM SoC's).
> >
> > It is true that for subsystems which rely on the core component being
> > explicitly enabled, they often tend to hide drivers which depend on it
> > from the menu unless it is. This also makes sense.
> >
> >> 
> >> Is there something that requires such a different/unusual
behaviour in
> >> remoteproc ?
> >> 
> >
> > I'm not sure it is that unusual...looking at config USB, it
selects USB_COMMON in
> > mfd subsystem, client drivers select MFD_CORE.
> >
> > I've added Arnd to this thread, as I've seen lots of Kconfig
patches from him
> > recently, maybe he has some thoughts on whether this is the correct
fix or not?
> 
> 
> Documentation/kbuild/kconfig-language.txt:
> 
>   Note:
> 	select should be used with care. select will force
> 	a symbol to a value without visiting the dependencies.
> 	By abusing select you are able to select a symbol FOO even
> 	if FOO depends on BAR that is not set.
> 	In general use select only for non-visible symbols
> 	(no prompts anywhere) and for symbols with no dependencies.
> 	That will limit the usefulness but on the other hand avoid
> 	the illegal configurations all over.
Thanks for the documentation link. I believe this proves this patch is an
appropriate fix as VIRTIO is a non-visible symbol, and has no dependencies.

In fact the help text for VIRTIO even states this option should be selected
by any driver which implements virtio.
> 
> People tend to abuse select because it's "convenient". If you
depend,
> but some of your dependencies aren't met, you're in for some
digging
> through Kconfig to find the missing deps. Just to make the option you
> want visible in menuconfig. If you instead select something with
> dependencies, it'll be right most of the time, and it's
"convenient",
> until it breaks. (And hey, it usually breaks for someone else with some
> other config, so it's still convenient for you.)
I'm sure they do but in this case it is actually the use of 'depends
on'
which has caused the breakage and inconvenience for somebody else and sadly this
inconvienice is still on-going due to this patch not being applied or getting an
acked-by from the appropriate maintainers.
> 
> Perhaps kconfig should complain about selecting visible symbols and
> symbols with dependencies.
That sounds like it would be a useful addition.

Is it possible to get this patch applied or an acked-by to avoid further delay
to the fdma series?

regards,

Peter.

On 6 October 2016 at 10:37, Peter Griffin <peter.griffin at linaro.org>
wrote:
> In fact the help text for VIRTIO even states this option should be selected
> by any driver which implements virtio.
>
Almost but not quite. It says:

"This option is selected by any driver which implements the virtio
_bus_"

REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
the latter should _not_ select, be that explicitly or implicitly via
REMOTEPROC, the symbol.
>>
>> People tend to abuse select because it's "convenient". If
you depend,
>> but some of your dependencies aren't met, you're in for some
digging
>> through Kconfig to find the missing deps. Just to make the option you
>> want visible in menuconfig. If you instead select something with
>> dependencies, it'll be right most of the time, and it's
"convenient",
>> until it breaks. (And hey, it usually breaks for someone else with some
>> other config, so it's still convenient for you.)
>
> I'm sure they do but in this case it is actually the use of
'depends on'
> which has caused the breakage and inconvenience for somebody else and sadly
this
> inconvienice is still on-going due to this patch not being applied or
getting an
> acked-by from the appropriate maintainers.
>
Surely you're not saying that pre-existing driver following the
documentation, is 'causing breakage' for a new driver {ab,mis}using a
feature ?

This reminds me an old saying: "If the shoe doesn?t fit, it doesn?t
mean there is anything wrong with your feet."
You seem to be suggesting the opposite ?
>>
>> Perhaps kconfig should complain about selecting visible symbols and
>> symbols with dependencies.
>
> That sounds like it would be a useful addition.
>
> Is it possible to get this patch applied or an acked-by to avoid further
delay
> to the fdma series?
>
Please don't apply duct tape, especially where it's _not_ needed.

$ sed -i s/select REMOTEPROC/depends on REMOTEPROC/ drivers/remoteproc/Kconfig

... will resolve things in the right place. The alternative will lead
to random issues in other subsystems.

Regards,
Emil

Hi Emil,

On Thu, 06 Oct 2016, Emil Velikov wrote:
> On 6 October 2016 at 10:37, Peter Griffin <peter.griffin at
linaro.org> wrote:
> 
> > In fact the help text for VIRTIO even states this option should be
selected
> > by any driver which implements virtio.
> >
> Almost but not quite. It says:
> 
> "This option is selected by any driver which implements the virtio
_bus_"
> 
Ah I thought DRM_VIRTIO_GPU was implementing a virtio bus, bus it seems that it 
uses pci. Which does raise the question of why it is depending on VIRTIO at all
and not VIRTIO_PCI.
> REMOTEPROC obviously does that while the ST SLIM driver does not. Thus
> the latter should _not_ select, be that explicitly or implicitly via
> REMOTEPROC, the symbol.
Yep OK.
> 
> >>
> >> People tend to abuse select because it's
"convenient". If you depend,
> >> but some of your dependencies aren't met, you're in for
some digging
> >> through Kconfig to find the missing deps. Just to make the option
you
> >> want visible in menuconfig. If you instead select something with
> >> dependencies, it'll be right most of the time, and it's
"convenient",
> >> until it breaks. (And hey, it usually breaks for someone else with
some
> >> other config, so it's still convenient for you.)
> >
> > I'm sure they do but in this case it is actually the use of
'depends on'
> > which has caused the breakage and inconvenience for somebody else and
sadly this
> > inconvienice is still on-going due to this patch not being applied or
getting an
> > acked-by from the appropriate maintainers.
> >
> Surely you're not saying that pre-existing driver following the
> documentation, is 'causing breakage' for a new driver {ab,mis}using
a
> feature ?
Your right I wasn't saying that :)

My point was that this patch wasn't 'wrong' when referring to the
Kconfig
documentation Jani referenced as VIRTIO has no dependencies.

Also I thought DRM_VIRTIO_GPU driver implemented a VIRTIO bus which re-enforced
the view that it should be selecting VIRTIO. 
> 
> This reminds me an old saying: "If the shoe doesn?t fit, it doesn?t
> mean there is anything wrong with your feet."
If the shoe doesn't fit, chop off the leg :)
> You seem to be suggesting the opposite ?
> 
> >>
> >> Perhaps kconfig should complain about selecting visible symbols
and
> >> symbols with dependencies.
> >
> > That sounds like it would be a useful addition.
> >
> > Is it possible to get this patch applied or an acked-by to avoid
further delay
> > to the fdma series?
> >
> Please don't apply duct tape, especially where it's _not_ needed.
> 
> $ sed -i s/select REMOTEPROC/depends on REMOTEPROC/
drivers/remoteproc/Kconfig
> 
> ... will resolve things in the right place. The alternative will lead
> to random issues in other subsystems.
> 
If Bjorn is OK with it, then it is fine with me.

I will update remoteproc Kconfig setup in fdma v10, this will drop the
requirement for this patch in drm subsystem.

I can then send the whitespace cleanup patch separately to DRM ML.

regards,

Peter.