Hi,
I have an idea to improve the Kconfig dependencies, especially for
subsystem maintainers. First a bit of history:
I recently changed the Kconfig rules for omapdss driver to not depend on
OMAP platform, as the driver itself uses no OMAP specific APIs, and can
be compiled fine on, say, x86.
This got nack'ed by Linus, as omapdss is used only on OMAP, and allowing
it to be visible for other platforms is just extra clutter. I think
that's a valid point.
However, I think there are valid cases to allow a driver to be compiled
for other platforms. First two are quite minor, but I think the third
one is a major use case. I say here "omapdss" but you can replace it
with any driver that has build dependency to some platform.
1) Building omapdss with arm compiler should show all relevant warnings,
but in reality it seems that the compilers for different architectures
have slightly different behaviors. Building omapdss with a compiler for
other architecture is a good way to check for any possible errors. Also,
direct arch dependencies in a driver are generally a mistake, and
compiling with another compiler would bring these issues up.
2) When developing a new SoC, the IP in question could be in a, say,
FPGA board, attached to a PC. The same driver would thus be needed for
x86 also.
3) When making changes which affect drivers for multiple platforms (say,
fbdev changes), it is very difficult to compile test the changes. I
recently made changes to a bunch of fb drivers, and I think I managed to
compile only a few of them. To compile them all, I'd need to install all
the various cross compilers and find out which kind of kernel config is
needed to get the driver enabled.
If, on the other hand, the drivers would only depend on things they need
to get compiled, it gets much easier to compile test.
So, my idea is to have a new kind of Kconfig dependency. I'll call it
"softdepends" in lack of better name. A driver maintainer could use
"softdepends on ARCH_OMAP", instead of "depends on ARCH_OMAP", to say
that this driver does not actually build depend on ARCH_OMAP, but for
all normal purposes it does.
Normally, this would result in the same behavior as the normal
"depends", and Linus would not get a questions whether he wants to
enable this OMAP specific driver or not, and the driver would not be
visible on the menuconfig.
But the user could enable the driver if he explicitly so wants. Perhaps
a Kconfig option such as "ignore softdepends", enabling of which would
allow the user to enable the drivers that use softdepends. Or, maybe
just require the user to add the config option manually into his .config.
Now, I don't have much knowledge of the Kconfig internals, so the above
implementation ideas are just rough ideas to show the point.
Thoughts?
Tomi
>
> So, my idea is to have a new kind of Kconfig dependency. I'll call it
> "softdepends" in lack of better name. A driver maintainer could use
> "softdepends on ARCH_OMAP", instead of "depends on ARCH_OMAP", to say
> that this driver does not actually build depend on ARCH_OMAP, but for
> all normal purposes it does.
>
> Normally, this would result in the same behavior as the normal
> "depends", and Linus would not get a questions whether he wants to
> enable this OMAP specific driver or not, and the driver would not be
> visible on the menuconfig.
>
> But the user could enable the driver if he explicitly so wants. Perhaps
> a Kconfig option such as "ignore softdepends", enabling of which would
> allow the user to enable the drivers that use softdepends. Or, maybe
> just require the user to add the config option manually into his .config.
If I understand you correct this is already possible today without
extending the kconfig language.
config OMAP_SPECIFIC_DRIVER
depends on ARCH_OMAP || SHOW_ALL_DRIVERS
If SHOW_ALL_DRIVERS are "y" then user can say "y" to the OMAP specific driver too,
even without ARCH_OMAP being selected.
Sam
Hi,
On Tue, Apr 30, 2013 at 12:24:40PM +0200, Sam Ravnborg wrote:
> > So, my idea is to have a new kind of Kconfig dependency. I'll call it
> > "softdepends" in lack of better name. A driver maintainer could use
> > "softdepends on ARCH_OMAP", instead of "depends on ARCH_OMAP", to say
> > that this driver does not actually build depend on ARCH_OMAP, but for
> > all normal purposes it does.
> >
> > Normally, this would result in the same behavior as the normal
> > "depends", and Linus would not get a questions whether he wants to
> > enable this OMAP specific driver or not, and the driver would not be
> > visible on the menuconfig.
> >
> > But the user could enable the driver if he explicitly so wants. Perhaps
> > a Kconfig option such as "ignore softdepends", enabling of which would
> > allow the user to enable the drivers that use softdepends. Or, maybe
> > just require the user to add the config option manually into his .config.
>
> If I understand you correct this is already possible today without
> extending the kconfig language.
>
> config OMAP_SPECIFIC_DRIVER
> depends on ARCH_OMAP || SHOW_ALL_DRIVERS
>
>
> If SHOW_ALL_DRIVERS are "y" then user can say "y" to the OMAP specific
> driver too, even without ARCH_OMAP being selected.
SHOW_ALL_DRIVERS might create another set of issues. If Linus isn't
taking patches removing 'depends on ARCH_OMAP' would he take patches
adding SHOW_ALL_DRIVERS ?
I think something like 'available on ARCH_OMAP' might be useful,
however. We could start converting depends on ARCH_* into available on
ARCH_* and when build testing we could:
$ make DEBUG_IGNORE_ARCH=y allmodconfig
$ make drivers/usb/host/
Would this be acceptable ?
--
balbi
On 04/30/2013 01:33 PM, Felipe Balbi wrote:
> Hi,
>
> On Tue, Apr 30, 2013 at 12:24:40PM +0200, Sam Ravnborg wrote:
>>> So, my idea is to have a new kind of Kconfig dependency. I'll call it
>>> "softdepends" in lack of better name. A driver maintainer could use
>>> "softdepends on ARCH_OMAP", instead of "depends on ARCH_OMAP", to say
>>> that this driver does not actually build depend on ARCH_OMAP, but for
>>> all normal purposes it does.
>>>
>>> Normally, this would result in the same behavior as the normal
>>> "depends", and Linus would not get a questions whether he wants to
>>> enable this OMAP specific driver or not, and the driver would not be
>>> visible on the menuconfig.
>>>
>>> But the user could enable the driver if he explicitly so wants. Perhaps
>>> a Kconfig option such as "ignore softdepends", enabling of which would
>>> allow the user to enable the drivers that use softdepends. Or, maybe
>>> just require the user to add the config option manually into his .config.
>>
>> If I understand you correct this is already possible today without
>> extending the kconfig language.
>>
>> config OMAP_SPECIFIC_DRIVER
>> depends on ARCH_OMAP || SHOW_ALL_DRIVERS
>>
>>
>> If SHOW_ALL_DRIVERS are "y" then user can say "y" to the OMAP specific
>> driver too, even without ARCH_OMAP being selected.
>
> SHOW_ALL_DRIVERS might create another set of issues. If Linus isn't
> taking patches removing 'depends on ARCH_OMAP' would he take patches
> adding SHOW_ALL_DRIVERS ?
Wouldn't the SHOW_ALL_DRIVERS be just a one time query from Kconfig to
the user? So Linus only needs to say "n" once. Why would he object to that?
Then again, as a personal opinion, "depends on ARCH_OMAP ||
SHOW_ALL_DRIVERS" is not very descriptive. I'm not sure if that matters,
though. One doesn't need to read the Kconfig files every day =).
But presuming most of the drivers would use that, it would add quite a
bit of repetition to the Kconfig files. Well, ok, I have no idea how
many drivers have dependencies that could be removed.
So SHOW_ALL_DRIVERS sounds quite an easy solution to this.
Tomi
On Tue, Apr 30, 2013 at 01:33:18PM +0300, Felipe Balbi wrote:
>
> I think something like 'available on ARCH_OMAP' might be useful,
> however.
In general I try to avoid extending the Kconfig language.
Let's try to keep it simple.
So as long as we can do it within the current language let's not invent
something new.
Sam
> SHOW_ALL_DRIVERS" is not very descriptive. I'm not sure if that matters,
> though. One doesn't need to read the Kconfig files every day =).
>
> But presuming most of the drivers would use that, it would add quite a
> bit of repetition to the Kconfig files. Well, ok, I have no idea how
> many drivers have dependencies that could be removed.
>
> So SHOW_ALL_DRIVERS sounds quite an easy solution to this.
Someone suggested to add symbols that are only set yo "y" for allyesconfig or allmodconfig.
This would be what you actuayl require here as what you are after is better
build coverage.
But we should not annouyt the user just to get better build coverage - which
is why hiding irrelevant symbols is good.
Sam
On 04/30/2013 02:40 PM, Sam Ravnborg wrote:
>> SHOW_ALL_DRIVERS" is not very descriptive. I'm not sure if that matters,
>> though. One doesn't need to read the Kconfig files every day =).
>>
>> But presuming most of the drivers would use that, it would add quite a
>> bit of repetition to the Kconfig files. Well, ok, I have no idea how
>> many drivers have dependencies that could be removed.
>>
>> So SHOW_ALL_DRIVERS sounds quite an easy solution to this.
>
> Someone suggested to add symbols that are only set yo "y" for allyesconfig or allmodconfig.
> This would be what you actuayl require here as what you are after is better
> build coverage.
Sorry, I didn't quite get this. Do you mean that if I do allyesconfig,
SHOW_ALL_DRIVERS would get enabled, but not otherwise?
> But we should not annouyt the user just to get better build coverage - which
> is why hiding irrelevant symbols is good.
No disagreement there.
But I must say good build coverage is also important (I broke a powerpc
fb driver compilation with my mmap changes, and after fixing the
compilation I introduced a warning...). So I think it's a worthy goal to
have most of the drivers arch-independent, and make it possible to build
them if the user so wants.
I'll do a bit experimenting with fb drivers to see how the
SHOW_ALL_DRIVERS would work. And if there are any other fb drivers than
omapfb that actually can be compiled on other archs.
Tomi