Re: [PATCH] build some drivers only when compile-testing

Re: [PATCH] build some drivers only when compile-testing

[Greg Kroah-Hartman]

On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> Some drivers can be built on more platforms than they run on. This
> causes users and distributors packaging burden when they have to
> manually deselect some drivers from their allmodconfigs. Or sometimes
> it is even impossible to disable the drivers without patching the
> kernel.
> 
> Introduce a new config option COMPILE_TEST and make all those drivers
> to depend on the platform they run on, or on the COMPILE_TEST option.
> Now, when users/distributors choose COMPILE_TEST=n they will not have
> the drivers in their allmodconfig setups, but developers still can
> compile-test them with COMPILE_TEST=y.

I understand the urge, and it's getting hard for distros to handle these
drivers that just don't work on other architectures, but it's really
valuable to ensure that they build properly, for those of us that don't
have many/any cross compilers set up.

> Now the drivers where we use this new option:
> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
>   processors so it should depend on x86.
> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
>   systems -- which do not actually support the hardware via that
>   method.

This seems ripe to start to get really messy, really quickly.  Shouldn't
"default configs" handle if this "should" be enabled for a platform or
not, and let the rest of us just build them with no problems?

What problems is this causing you?  Are you running out of space in
kernel packages with drivers that will never be actually used?

> +config COMPILE_TEST
> +	bool "Compile also drivers which will not load" if EXPERT

EXPERT is getting to be the "let's hide it here" option, isn't it...

I don't know, if no one else strongly objects, I can be convinced that
this is needed, but so far, I don't see why it really is, or what this
is going to help with.

thanks,

greg k-h

Re: [PATCH] build some drivers only when compile-testing

[Jeff Mahoney]

On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
>> Some drivers can be built on more platforms than they run on. This
>> causes users and distributors packaging burden when they have to
>> manually deselect some drivers from their allmodconfigs. Or sometimes
>> it is even impossible to disable the drivers without patching the
>> kernel.
>>
>> Introduce a new config option COMPILE_TEST and make all those drivers
>> to depend on the platform they run on, or on the COMPILE_TEST option.
>> Now, when users/distributors choose COMPILE_TEST=n they will not have
>> the drivers in their allmodconfig setups, but developers still can
>> compile-test them with COMPILE_TEST=y.
> 
> I understand the urge, and it's getting hard for distros to handle these
> drivers that just don't work on other architectures, but it's really
> valuable to ensure that they build properly, for those of us that don't
> have many/any cross compilers set up.
> 
>> Now the drivers where we use this new option:
>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
>>   processors so it should depend on x86.
>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
>>   systems -- which do not actually support the hardware via that
>>   method.
> 
> This seems ripe to start to get really messy, really quickly.  Shouldn't
> "default configs" handle if this "should" be enabled for a platform or
> not, and let the rest of us just build them with no problems?

If every time a new Kconfig option is added, corresponding default
config updates come with it, sure. I just don't see that happening,
especially when it can be done much more clearly in the Kconfig while
the developer is writing the driver.

> What problems is this causing you?  Are you running out of space in
> kernel packages with drivers that will never be actually used?

Wasted build resources. Wasted disk space on /every/ system the kernel
package is installed on. We're all trying to pare down the kernel
packages to eliminate wasted space and doing it manually means a bunch
of research, sometimes with incorrect assumptions about the results,
needs to be done by someone not usually associated with that code. That
research gets repeated by people maintaining kernel packages for pretty
much every distro.

>> +config COMPILE_TEST
>> +	bool "Compile also drivers which will not load" if EXPERT
> 
> EXPERT is getting to be the "let's hide it here" option, isn't it...
> 
> I don't know, if no one else strongly objects, I can be convinced that
> this is needed, but so far, I don't see why it really is, or what this
> is going to help with.

I'm not convinced adding a || COMPILE_TEST option to every driver that
may be arch specific is the best way to go either. Perhaps adding a new
Kconfig verb called "archdepends on" or something that will evaluate as
true if COMPILE_TEST is enabled but will evaluate the conditional if
not. *waves hands*

-Jeff

-- 
Jeff Mahoney
SUSE Labs

Re: [PATCH] build some drivers only when compile-testing

[Jiri Slaby]

[-- Attachment #1: Type: text/plain, Size: 3819 bytes --]

On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
>>> Some drivers can be built on more platforms than they run on. This
>>> causes users and distributors packaging burden when they have to
>>> manually deselect some drivers from their allmodconfigs. Or sometimes
>>> it is even impossible to disable the drivers without patching the
>>> kernel.
>>>
>>> Introduce a new config option COMPILE_TEST and make all those drivers
>>> to depend on the platform they run on, or on the COMPILE_TEST option.
>>> Now, when users/distributors choose COMPILE_TEST=n they will not have
>>> the drivers in their allmodconfig setups, but developers still can
>>> compile-test them with COMPILE_TEST=y.
>>
>> I understand the urge, and it's getting hard for distros to handle these
>> drivers that just don't work on other architectures, but it's really
>> valuable to ensure that they build properly, for those of us that don't
>> have many/any cross compilers set up.

But this is exactly what COMPILE_TEST will give us when set to "y", or
am I missing something?

>>> Now the drivers where we use this new option:
>>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
>>>   processors so it should depend on x86.
>>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
>>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
>>>   systems -- which do not actually support the hardware via that
>>>   method.
>>
>> This seems ripe to start to get really messy, really quickly.  Shouldn't
>> "default configs" handle if this "should" be enabled for a platform or
>> not, and let the rest of us just build them with no problems?
> 
> If every time a new Kconfig option is added, corresponding default
> config updates come with it, sure. I just don't see that happening,
> especially when it can be done much more clearly in the Kconfig while
> the developer is writing the driver.
> 
>> What problems is this causing you?  Are you running out of space in
>> kernel packages with drivers that will never be actually used?
> 
> Wasted build resources. Wasted disk space on /every/ system the kernel
> package is installed on. We're all trying to pare down the kernel
> packages to eliminate wasted space and doing it manually means a bunch
> of research, sometimes with incorrect assumptions about the results,
> needs to be done by someone not usually associated with that code. That
> research gets repeated by people maintaining kernel packages for pretty
> much every distro.

I second all the above.

>>> +config COMPILE_TEST
>>> +	bool "Compile also drivers which will not load" if EXPERT
>>
>> EXPERT is getting to be the "let's hide it here" option, isn't it...
>>
>> I don't know, if no one else strongly objects, I can be convinced that
>> this is needed, but so far, I don't see why it really is, or what this
>> is going to help with.
> 
> I'm not convinced adding a || COMPILE_TEST option to every driver that
> may be arch specific is the best way to go either. Perhaps adding a new
> Kconfig verb called "archdepends on" or something that will evaluate as
> true if COMPILE_TEST is enabled but will evaluate the conditional if
> not. *waves hands*

Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
to extend the kconfig language for this purpose (which I support). That
a config option is fine and sufficient in this case [1]. Except he
called the config option "SHOW_ALL_DRIVERS". Adding the current
maintainer to CCs ;).

[1] http://comments.gmane.org/gmane.linux.kbuild.devel/9829

The last point I inclined to the Greg's argument to remove the EXPERT
dependency.

So currently I have what is attached... Comments?

thanks,
-- 
js
suse labs

[-- Attachment #2: 0001-build-some-drivers-only-when-compile-testing.patch --]
[-- Type: text/x-patch, Size: 5332 bytes --]

From e818e90b4f901c8d949d08bd05735203c5e88530 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Wed, 22 May 2013 10:56:24 +0200
Subject: [PATCH v2] build some drivers only when compile-testing

Some drivers can be built on more platforms than they run on. This is
a burden for users and distributors who package a kernel. They have to
manually deselect some (for them useless) drivers when updating their
configs via oldconfig. And yet, sometimes it is even impossible to
disable the drivers without patching the kernel.

Introduce a new config option COMPILE_TEST and make all those drivers
to depend on the platform they run on, or on the COMPILE_TEST option.
Now, when users/distributors choose COMPILE_TEST=n they will not have
the drivers in their allmodconfig setups, but developers still can
compile-test them with COMPILE_TEST=y.

Now the drivers where we use this new option:
* PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
  processors so it should depend on x86.
* FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
* USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
  systems -- which do not actually support the hardware via that
  method.
* INTEL_MID_PTI: It is specific to the Penwell type of Intel Atom
  device.

[v2]
* remove EXPERT dependency

Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Jeff Mahoney <jeffm@suse.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: linux-usb@vger.kernel.org
Cc: Florian Tobias Schandinat <FlorianSchandinat@gmx.de>
Cc: linux-geode@lists.infradead.org
Cc: linux-fbdev@vger.kernel.org
Cc: Richard Cochran <richardcochran@gmail.com>
Cc: netdev@vger.kernel.org
Cc: Ben Hutchings <ben@decadent.org.uk>
Cc: "Keller, Jacob E" <jacob.e.keller@intel.com>
---
 drivers/misc/Kconfig          |  2 +-
 drivers/ptp/Kconfig           |  1 +
 drivers/usb/chipidea/Kconfig  |  6 ++++++
 drivers/usb/chipidea/Makefile |  4 +---
 drivers/video/geode/Kconfig   |  2 +-
 init/Kconfig                  | 14 ++++++++++++++
 6 files changed, 24 insertions(+), 5 deletions(-)

diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
index 80889d5..8dacd4c 100644
--- a/drivers/misc/Kconfig
+++ b/drivers/misc/Kconfig
@@ -135,7 +135,7 @@ config PHANTOM
 
 config INTEL_MID_PTI
 	tristate "Parallel Trace Interface for MIPI P1149.7 cJTAG standard"
-	depends on PCI && TTY
+	depends on PCI && TTY && (X86_INTEL_MID || COMPILE_TEST)
 	default n
 	help
 	  The PTI (Parallel Trace Interface) driver directs
diff --git a/drivers/ptp/Kconfig b/drivers/ptp/Kconfig
index 1ea6f1d..5be73ba 100644
--- a/drivers/ptp/Kconfig
+++ b/drivers/ptp/Kconfig
@@ -72,6 +72,7 @@ config DP83640_PHY
 
 config PTP_1588_CLOCK_PCH
 	tristate "Intel PCH EG20T as PTP clock"
+	depends on X86 || COMPILE_TEST
 	select PTP_1588_CLOCK
 	help
 	  This driver adds support for using the PCH EG20T as a PTP
diff --git a/drivers/usb/chipidea/Kconfig b/drivers/usb/chipidea/Kconfig
index b2df442..3491d86 100644
--- a/drivers/usb/chipidea/Kconfig
+++ b/drivers/usb/chipidea/Kconfig
@@ -31,4 +31,10 @@ config USB_CHIPIDEA_DEBUG
 	help
 	  Say Y here to enable debugging output of the ChipIdea driver.
 
+config USB_CHIPIDEA_IMX
+	bool "ChipIdea IMX support"
+	depends on OF_DEVICE && (ARM || COMPILE_TEST)
+	help
+	  This option enables ChipIdea support on IMX.
+
 endif
diff --git a/drivers/usb/chipidea/Makefile b/drivers/usb/chipidea/Makefile
index 4113feb..76d66ff 100644
--- a/drivers/usb/chipidea/Makefile
+++ b/drivers/usb/chipidea/Makefile
@@ -16,6 +16,4 @@ ifneq ($(CONFIG_PCI),)
 	obj-$(CONFIG_USB_CHIPIDEA)	+= ci13xxx_pci.o
 endif
 
-ifneq ($(CONFIG_OF),)
-	obj-$(CONFIG_USB_CHIPIDEA)	+= ci13xxx_imx.o usbmisc_imx.o
-endif
+obj-$(CONFIG_USB_CHIPIDEA_IMX)	+= ci13xxx_imx.o usbmisc_imx.o
diff --git a/drivers/video/geode/Kconfig b/drivers/video/geode/Kconfig
index 21e351a..1e85552 100644
--- a/drivers/video/geode/Kconfig
+++ b/drivers/video/geode/Kconfig
@@ -3,7 +3,7 @@
 #
 config FB_GEODE
 	bool "AMD Geode family framebuffer support"
-	depends on FB && PCI && X86
+	depends on FB && PCI && (X86_32 || (X86 && COMPILE_TEST))
 	---help---
 	  Say 'Y' here to allow you to select framebuffer drivers for
 	  the AMD Geode family of processors.
diff --git a/init/Kconfig b/init/Kconfig
index fd0e436..e1854b2 100644
--- a/init/Kconfig
+++ b/init/Kconfig
@@ -53,6 +53,20 @@ config CROSS_COMPILE
 	  need to set this unless you want the configured kernel build
 	  directory to select the cross-compiler automatically.
 
+config COMPILE_TEST
+	bool "Compile also drivers which will not load"
+	default n
+	help
+	  Some drivers can be compiled on a different platform than they are
+	  intended to be run on. Despite they cannot be loaded there (or even
+	  when they load they cannot be used due to missing HW support),
+	  developers still, opposing to distributors, might want to build such
+	  drivers to compile-test them.
+
+	  If you are a developer and want to build everything available, say Y
+	  here. If you are a user/distributor, say N here to exclude useless
+	  drivers to be distributed.
+
 config LOCALVERSION
 	string "Local version - append to kernel release"
 	help
-- 
1.8.3

Re: [PATCH] build some drivers only when compile-testing

[Michal Marek]

Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
> On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
>> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
>>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
>>>> Some drivers can be built on more platforms than they run on. This
>>>> causes users and distributors packaging burden when they have to
>>>> manually deselect some drivers from their allmodconfigs. Or sometimes
>>>> it is even impossible to disable the drivers without patching the
>>>> kernel.
>>>>
>>>> Introduce a new config option COMPILE_TEST and make all those drivers
>>>> to depend on the platform they run on, or on the COMPILE_TEST option.
>>>> Now, when users/distributors choose COMPILE_TEST=n they will not have
>>>> the drivers in their allmodconfig setups, but developers still can
>>>> compile-test them with COMPILE_TEST=y.
>>>
>>> I understand the urge, and it's getting hard for distros to handle these
>>> drivers that just don't work on other architectures, but it's really
>>> valuable to ensure that they build properly, for those of us that don't
>>> have many/any cross compilers set up.
> 
> But this is exactly what COMPILE_TEST will give us when set to "y", or
> am I missing something?
> 
>>>> Now the drivers where we use this new option:
>>>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
>>>>   processors so it should depend on x86.
>>>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
>>>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
>>>>   systems -- which do not actually support the hardware via that
>>>>   method.
>>>
>>> This seems ripe to start to get really messy, really quickly.  Shouldn't
>>> "default configs" handle if this "should" be enabled for a platform or
>>> not, and let the rest of us just build them with no problems?
>>
>> If every time a new Kconfig option is added, corresponding default
>> config updates come with it, sure. I just don't see that happening,
>> especially when it can be done much more clearly in the Kconfig while
>> the developer is writing the driver.
>>
>>> What problems is this causing you?  Are you running out of space in
>>> kernel packages with drivers that will never be actually used?
>>
>> Wasted build resources. Wasted disk space on /every/ system the kernel
>> package is installed on. We're all trying to pare down the kernel
>> packages to eliminate wasted space and doing it manually means a bunch
>> of research, sometimes with incorrect assumptions about the results,
>> needs to be done by someone not usually associated with that code. That
>> research gets repeated by people maintaining kernel packages for pretty
>> much every distro.
> 
> I second all the above.
> 
>>>> +config COMPILE_TEST
>>>> +	bool "Compile also drivers which will not load" if EXPERT
>>>
>>> EXPERT is getting to be the "let's hide it here" option, isn't it...
>>>
>>> I don't know, if no one else strongly objects, I can be convinced that
>>> this is needed, but so far, I don't see why it really is, or what this
>>> is going to help with.
>>
>> I'm not convinced adding a || COMPILE_TEST option to every driver that
>> may be arch specific is the best way to go either. Perhaps adding a new
>> Kconfig verb called "archdepends on" or something that will evaluate as
>> true if COMPILE_TEST is enabled but will evaluate the conditional if
>> not. *waves hands*
> 
> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
> to extend the kconfig language for this purpose (which I support). That
> a config option is fine and sufficient in this case [1]. Except he
> called the config option "SHOW_ALL_DRIVERS". Adding the current
> maintainer to CCs ;).

I agree with Sam. 'depends on XY || COMPILE_TEST' is quite
self-explanatory. And even if it's not, you can look up the help text
for COMPILE_TEST. With "archdepends on" or "available on", you need to
know what to look for to override the dependency.

Michal

Re: [PATCH] build some drivers only when compile-testing

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 4500 bytes --]

Hi,

On Tue, Jun 18, 2013 at 06:51:32AM +0200, Michal Marek wrote:
> Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
> > On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
> >> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
> >>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> >>>> Some drivers can be built on more platforms than they run on. This
> >>>> causes users and distributors packaging burden when they have to
> >>>> manually deselect some drivers from their allmodconfigs. Or sometimes
> >>>> it is even impossible to disable the drivers without patching the
> >>>> kernel.
> >>>>
> >>>> Introduce a new config option COMPILE_TEST and make all those drivers
> >>>> to depend on the platform they run on, or on the COMPILE_TEST option.
> >>>> Now, when users/distributors choose COMPILE_TEST=n they will not have
> >>>> the drivers in their allmodconfig setups, but developers still can
> >>>> compile-test them with COMPILE_TEST=y.
> >>>
> >>> I understand the urge, and it's getting hard for distros to handle these
> >>> drivers that just don't work on other architectures, but it's really
> >>> valuable to ensure that they build properly, for those of us that don't
> >>> have many/any cross compilers set up.
> > 
> > But this is exactly what COMPILE_TEST will give us when set to "y", or
> > am I missing something?
> > 
> >>>> Now the drivers where we use this new option:
> >>>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
> >>>>   processors so it should depend on x86.
> >>>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
> >>>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
> >>>>   systems -- which do not actually support the hardware via that
> >>>>   method.
> >>>
> >>> This seems ripe to start to get really messy, really quickly.  Shouldn't
> >>> "default configs" handle if this "should" be enabled for a platform or
> >>> not, and let the rest of us just build them with no problems?
> >>
> >> If every time a new Kconfig option is added, corresponding default
> >> config updates come with it, sure. I just don't see that happening,
> >> especially when it can be done much more clearly in the Kconfig while
> >> the developer is writing the driver.
> >>
> >>> What problems is this causing you?  Are you running out of space in
> >>> kernel packages with drivers that will never be actually used?
> >>
> >> Wasted build resources. Wasted disk space on /every/ system the kernel
> >> package is installed on. We're all trying to pare down the kernel
> >> packages to eliminate wasted space and doing it manually means a bunch
> >> of research, sometimes with incorrect assumptions about the results,
> >> needs to be done by someone not usually associated with that code. That
> >> research gets repeated by people maintaining kernel packages for pretty
> >> much every distro.
> > 
> > I second all the above.
> > 
> >>>> +config COMPILE_TEST
> >>>> +	bool "Compile also drivers which will not load" if EXPERT
> >>>
> >>> EXPERT is getting to be the "let's hide it here" option, isn't it...
> >>>
> >>> I don't know, if no one else strongly objects, I can be convinced that
> >>> this is needed, but so far, I don't see why it really is, or what this
> >>> is going to help with.
> >>
> >> I'm not convinced adding a || COMPILE_TEST option to every driver that
> >> may be arch specific is the best way to go either. Perhaps adding a new
> >> Kconfig verb called "archdepends on" or something that will evaluate as
> >> true if COMPILE_TEST is enabled but will evaluate the conditional if
> >> not. *waves hands*
> > 
> > Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
> > to extend the kconfig language for this purpose (which I support). That
> > a config option is fine and sufficient in this case [1]. Except he
> > called the config option "SHOW_ALL_DRIVERS". Adding the current
> > maintainer to CCs ;).
> 
> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite
> self-explanatory. And even if it's not, you can look up the help text
> for COMPILE_TEST. With "archdepends on" or "available on", you need to
> know what to look for to override the dependency.

you will still end up with:

depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC || ...)

And every now and again that particular line will be updated to add
another arch dependency.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Jiri Slaby]

On 06/18/2013 10:18 AM, Felipe Balbi wrote:
> Hi,
> 
> On Tue, Jun 18, 2013 at 06:51:32AM +0200, Michal Marek wrote:
>> Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
>>> On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
>>>> On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
>>>>> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby
>>>>> wrote:
>>>>>> Some drivers can be built on more platforms than they run
>>>>>> on. This causes users and distributors packaging burden
>>>>>> when they have to manually deselect some drivers from
>>>>>> their allmodconfigs. Or sometimes it is even impossible
>>>>>> to disable the drivers without patching the kernel.
>>>>>> 
>>>>>> Introduce a new config option COMPILE_TEST and make all
>>>>>> those drivers to depend on the platform they run on, or
>>>>>> on the COMPILE_TEST option. Now, when users/distributors
>>>>>> choose COMPILE_TEST=n they will not have the drivers in
>>>>>> their allmodconfig setups, but developers still can 
>>>>>> compile-test them with COMPILE_TEST=y.
>>>>> 
>>>>> I understand the urge, and it's getting hard for distros to
>>>>> handle these drivers that just don't work on other
>>>>> architectures, but it's really valuable to ensure that they
>>>>> build properly, for those of us that don't have many/any
>>>>> cross compilers set up.
>>> 
>>> But this is exactly what COMPILE_TEST will give us when set to
>>> "y", or am I missing something?
>>> 
>>>>>> Now the drivers where we use this new option: *
>>>>>> PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with
>>>>>> Intel Atom processors so it should depend on x86. *
>>>>>> FB_GEODE: Geode is 32-bit only so only enable it for
>>>>>> X86_32. * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will
>>>>>> be met on powerpc systems -- which do not actually
>>>>>> support the hardware via that method.
>>>>> 
>>>>> This seems ripe to start to get really messy, really
>>>>> quickly.  Shouldn't "default configs" handle if this
>>>>> "should" be enabled for a platform or not, and let the rest
>>>>> of us just build them with no problems?
>>>> 
>>>> If every time a new Kconfig option is added, corresponding
>>>> default config updates come with it, sure. I just don't see
>>>> that happening, especially when it can be done much more
>>>> clearly in the Kconfig while the developer is writing the
>>>> driver.
>>>> 
>>>>> What problems is this causing you?  Are you running out of
>>>>> space in kernel packages with drivers that will never be
>>>>> actually used?
>>>> 
>>>> Wasted build resources. Wasted disk space on /every/ system
>>>> the kernel package is installed on. We're all trying to pare
>>>> down the kernel packages to eliminate wasted space and doing
>>>> it manually means a bunch of research, sometimes with
>>>> incorrect assumptions about the results, needs to be done by
>>>> someone not usually associated with that code. That research
>>>> gets repeated by people maintaining kernel packages for
>>>> pretty much every distro.
>>> 
>>> I second all the above.
>>> 
>>>>>> +config COMPILE_TEST +	bool "Compile also drivers which
>>>>>> will not load" if EXPERT
>>>>> 
>>>>> EXPERT is getting to be the "let's hide it here" option,
>>>>> isn't it...
>>>>> 
>>>>> I don't know, if no one else strongly objects, I can be
>>>>> convinced that this is needed, but so far, I don't see why
>>>>> it really is, or what this is going to help with.
>>>> 
>>>> I'm not convinced adding a || COMPILE_TEST option to every
>>>> driver that may be arch specific is the best way to go
>>>> either. Perhaps adding a new Kconfig verb called "archdepends
>>>> on" or something that will evaluate as true if COMPILE_TEST
>>>> is enabled but will evaluate the conditional if not. *waves
>>>> hands*
>>> 
>>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he
>>> doesn't want to extend the kconfig language for this purpose
>>> (which I support). That a config option is fine and sufficient
>>> in this case [1]. Except he called the config option
>>> "SHOW_ALL_DRIVERS". Adding the current maintainer to CCs ;).
>> 
>> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite 
>> self-explanatory. And even if it's not, you can look up the help
>> text for COMPILE_TEST. With "archdepends on" or "available on",
>> you need to know what to look for to override the dependency.
> 
> you will still end up with:
> 
> depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC ||
> ...)
> 
> And every now and again that particular line will be updated to
> add another arch dependency.

But that is perfectly fine *when* the driver is supported on those
archs only.

And come on, how much often will this "every now and again" happen? We
don't have that much cases where a driver is augmented to work on
another arch or platform. It either works on all of them => doesn't
need COMPILE_TEST, or work on one or two arches at most.

-- 
js
suse labs

Re: [PATCH] build some drivers only when compile-testing

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 1729 bytes --]

Hi,

On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
> >>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he
> >>> doesn't want to extend the kconfig language for this purpose
> >>> (which I support). That a config option is fine and sufficient
> >>> in this case [1]. Except he called the config option
> >>> "SHOW_ALL_DRIVERS". Adding the current maintainer to CCs ;).
> >> 
> >> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite 
> >> self-explanatory. And even if it's not, you can look up the help
> >> text for COMPILE_TEST. With "archdepends on" or "available on",
> >> you need to know what to look for to override the dependency.
> > 
> > you will still end up with:
> > 
> > depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI || ARCH_PPC ||
> > ...)
> > 
> > And every now and again that particular line will be updated to
> > add another arch dependency.
> 
> But that is perfectly fine *when* the driver is supported on those
> archs only.
> 
> And come on, how much often will this "every now and again" happen? We
> don't have that much cases where a driver is augmented to work on
> another arch or platform. It either works on all of them => doesn't
> need COMPILE_TEST, or work on one or two arches at most.

MUSB alone has 8 different arch choices. Before, it used to be that core
driver was dependendent on all of them, so whenever someone wanted to
build MUSB for another arch, they had to introdude their glue code and
modify the dependency of the core driver.

Also EHCI, it works on pretty much everything, so does DWC3.

DWC3 already has three possibilities but I know of at least 3 others
which could show up soonish.

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Michal Marek]

Dne 18.6.2013 10:34, Felipe Balbi napsal(a):
> Hi,
> 
> On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
>>>>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that
>>>>> he doesn't want to extend the kconfig language for this
>>>>> purpose (which I support). That a config option is fine and
>>>>> sufficient in this case [1]. Except he called the config
>>>>> option "SHOW_ALL_DRIVERS". Adding the current maintainer to
>>>>> CCs ;).
>>>> 
>>>> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite 
>>>> self-explanatory. And even if it's not, you can look up the
>>>> help text for COMPILE_TEST. With "archdepends on" or
>>>> "available on", you need to know what to look for to override
>>>> the dependency.
>>> 
>>> you will still end up with:
>>> 
>>> depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI ||
>>> ARCH_PPC || ...)
>>> 
>>> And every now and again that particular line will be updated
>>> to add another arch dependency.
>> 
>> But that is perfectly fine *when* the driver is supported on
>> those archs only.
>> 
>> And come on, how much often will this "every now and again"
>> happen? We don't have that much cases where a driver is augmented
>> to work on another arch or platform. It either works on all of
>> them => doesn't need COMPILE_TEST, or work on one or two arches
>> at most.
> 
> MUSB alone has 8 different arch choices. Before, it used to be that
> core driver was dependendent on all of them, so whenever someone
> wanted to build MUSB for another arch, they had to introdude their
> glue code and modify the dependency of the core driver.

But that you have complex dependencies in some drivers is mostly
orthogonal to the two choices of syntax, isn't it?

depends on ARCH1 || ARCH2 || .... || ARCH8 || COMPILE_TEST

vs.

archdepends on ARCH1 || ARCH2 || .... || ARCH8

Michal

Re: [PATCH] build some drivers only when compile-testing

[Felipe Balbi]

[-- Attachment #1: Type: text/plain, Size: 2279 bytes --]

Hi,

On Tue, Jun 18, 2013 at 10:44:52AM +0200, Michal Marek wrote:
> > On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
> >>>>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that
> >>>>> he doesn't want to extend the kconfig language for this
> >>>>> purpose (which I support). That a config option is fine and
> >>>>> sufficient in this case [1]. Except he called the config
> >>>>> option "SHOW_ALL_DRIVERS". Adding the current maintainer to
> >>>>> CCs ;).
> >>>> 
> >>>> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite 
> >>>> self-explanatory. And even if it's not, you can look up the
> >>>> help text for COMPILE_TEST. With "archdepends on" or
> >>>> "available on", you need to know what to look for to override
> >>>> the dependency.
> >>> 
> >>> you will still end up with:
> >>> 
> >>> depends on (ARCH_OMAP || ARCH_EXYNOS || ARCH_DAVINCI ||
> >>> ARCH_PPC || ...)
> >>> 
> >>> And every now and again that particular line will be updated
> >>> to add another arch dependency.
> >> 
> >> But that is perfectly fine *when* the driver is supported on
> >> those archs only.
> >> 
> >> And come on, how much often will this "every now and again"
> >> happen? We don't have that much cases where a driver is augmented
> >> to work on another arch or platform. It either works on all of
> >> them => doesn't need COMPILE_TEST, or work on one or two arches
> >> at most.
> > 
> > MUSB alone has 8 different arch choices. Before, it used to be that
> > core driver was dependendent on all of them, so whenever someone
> > wanted to build MUSB for another arch, they had to introdude their
> > glue code and modify the dependency of the core driver.
> 
> But that you have complex dependencies in some drivers is mostly
> orthogonal to the two choices of syntax, isn't it?
> 
> depends on ARCH1 || ARCH2 || .... || ARCH8 || COMPILE_TEST
> 
> vs.
> 
> archdepends on ARCH1 || ARCH2 || .... || ARCH8

right, but my argument is that I rather not have either. Depend on PCI
if you us PCI, depend on EXTCON if you use extcon, but no driver should
have an ARCH dependency. Specially since it lets people include mach/*
and asm/* headers because "it doesn't break compilation for anyone".

-- 
balbi

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Jiri Slaby]

On 06/18/2013 10:51 AM, Felipe Balbi wrote:
> right, but my argument is that I rather not have either. Depend on
> PCI if you us PCI, depend on EXTCON if you use extcon, but no
> driver should have an ARCH dependency. Specially since it lets
> people include mach/* and asm/* headers because "it doesn't break
> compilation for anyone".

The argument is elsewhere. If I understand correctly, Kconfig is for
users, not to be hi-jacked by kernel developers. And users should not
really care about our development processes, cross compilations or
whatever bells and whistles we use. They just don't want to see
drivers which they have no way to *use*, they indeed don't care
whether some more compile at all. We do not want every kernel packager
for every distro out in the wild, to go through all the help texts, to
see whether they should compile and package a driver or not. It's a
tedious work and this option would save time to the packagers.

Try to package and maintain a kernel for a distribution, you will find
out what a cool and surprising work that is...

In the best case I would vote for hard dependencies as cross-compilers
are easy to obtain and set up nowadays. But well, we still want to
("cross") compile drivers, so let's add COMPILE_TEST and use that to
save time to automatic builds.

-- 
js
suse labs

Re: [PATCH] build some drivers only when compile-testing

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 883 bytes --]

On Tue, Jun 18, 2013 at 11:34:26AM +0300, Felipe Balbi wrote:

> MUSB alone has 8 different arch choices. Before, it used to be that core
> driver was dependendent on all of them, so whenever someone wanted to
> build MUSB for another arch, they had to introdude their glue code and
> modify the dependency of the core driver.

> Also EHCI, it works on pretty much everything, so does DWC3.

> DWC3 already has three possibilities but I know of at least 3 others
> which could show up soonish.

If the number of architectures supported is getting large enough then
it's probably reasonable to just enable the driver all the time,
probably it'll also appear on some PCI cards or something anyway.  The
things people are complaining about here are things that are clearly
unlikely to appear on other architectures like a particular SoC vendor's
custom IPs that they don't license out.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1206 bytes --]

On 18/06/13 07:51, Michal Marek wrote:

>> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
>> to extend the kconfig language for this purpose (which I support). That
>> a config option is fine and sufficient in this case [1]. Except he
>> called the config option "SHOW_ALL_DRIVERS". Adding the current
>> maintainer to CCs ;).
> 
> I agree with Sam. 'depends on XY || COMPILE_TEST' is quite
> self-explanatory. And even if it's not, you can look up the help text
> for COMPILE_TEST. With "archdepends on" or "available on", you need to
> know what to look for to override the dependency.

I would rather have "depends on", when the code actually depends on
something (i.e. you can't compile/load the code otherwise), and "used
on"/"available on" when the code is just normally not used except on the
listed platforms (but nothing prevents from compiling and using the code
on all platforms).

But I'm fine with COMPILE_TEST or similar, I guess it's an acceptable
compromise and trivial to implement. Even if we had "used on" we'd still
need to update the Kconfig file when the code is being used on a new
platform, just like with COMPILE_TEST.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Greg Kroah-Hartman]

On Mon, Jun 17, 2013 at 10:05:19PM +0200, Jiri Slaby wrote:
> On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
> > On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
> >> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> >>> Some drivers can be built on more platforms than they run on. This
> >>> causes users and distributors packaging burden when they have to
> >>> manually deselect some drivers from their allmodconfigs. Or sometimes
> >>> it is even impossible to disable the drivers without patching the
> >>> kernel.
> >>>
> >>> Introduce a new config option COMPILE_TEST and make all those drivers
> >>> to depend on the platform they run on, or on the COMPILE_TEST option.
> >>> Now, when users/distributors choose COMPILE_TEST=n they will not have
> >>> the drivers in their allmodconfig setups, but developers still can
> >>> compile-test them with COMPILE_TEST=y.
> >>
> >> I understand the urge, and it's getting hard for distros to handle these
> >> drivers that just don't work on other architectures, but it's really
> >> valuable to ensure that they build properly, for those of us that don't
> >> have many/any cross compilers set up.
> 
> But this is exactly what COMPILE_TEST will give us when set to "y", or
> am I missing something?
> 
> >>> Now the drivers where we use this new option:
> >>> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
> >>>   processors so it should depend on x86.
> >>> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
> >>> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
> >>>   systems -- which do not actually support the hardware via that
> >>>   method.
> >>
> >> This seems ripe to start to get really messy, really quickly.  Shouldn't
> >> "default configs" handle if this "should" be enabled for a platform or
> >> not, and let the rest of us just build them with no problems?
> > 
> > If every time a new Kconfig option is added, corresponding default
> > config updates come with it, sure. I just don't see that happening,
> > especially when it can be done much more clearly in the Kconfig while
> > the developer is writing the driver.
> > 
> >> What problems is this causing you?  Are you running out of space in
> >> kernel packages with drivers that will never be actually used?
> > 
> > Wasted build resources. Wasted disk space on /every/ system the kernel
> > package is installed on. We're all trying to pare down the kernel
> > packages to eliminate wasted space and doing it manually means a bunch
> > of research, sometimes with incorrect assumptions about the results,
> > needs to be done by someone not usually associated with that code. That
> > research gets repeated by people maintaining kernel packages for pretty
> > much every distro.
> 
> I second all the above.
> 
> >>> +config COMPILE_TEST
> >>> +	bool "Compile also drivers which will not load" if EXPERT
> >>
> >> EXPERT is getting to be the "let's hide it here" option, isn't it...
> >>
> >> I don't know, if no one else strongly objects, I can be convinced that
> >> this is needed, but so far, I don't see why it really is, or what this
> >> is going to help with.
> > 
> > I'm not convinced adding a || COMPILE_TEST option to every driver that
> > may be arch specific is the best way to go either. Perhaps adding a new
> > Kconfig verb called "archdepends on" or something that will evaluate as
> > true if COMPILE_TEST is enabled but will evaluate the conditional if
> > not. *waves hands*
> 
> Sam Ravnborg (the kconfig ex-maintainer) once wrote that he doesn't want
> to extend the kconfig language for this purpose (which I support). That
> a config option is fine and sufficient in this case [1]. Except he
> called the config option "SHOW_ALL_DRIVERS". Adding the current
> maintainer to CCs ;).
> 
> [1] http://comments.gmane.org/gmane.linux.kbuild.devel/9829
> 
> The last point I inclined to the Greg's argument to remove the EXPERT
> dependency.
> 
> So currently I have what is attached... Comments?

Looks good to me, want me to queue it up through my char/misc driver
tree for 3.11?

thanks,

greg k-h

Re: [PATCH] build some drivers only when compile-testing

[Jiri Slaby]

On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
>> So currently I have what is attached... Comments?
> 
> Looks good to me, want me to queue it up through my char/misc driver
> tree for 3.11?

If there are no objections... Whoever picks that up, I would be happy 8-).

-- 
js
suse labs

Re: [PATCH] build some drivers only when compile-testing

[Greg Kroah-Hartman]

On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote:
> On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
> >> So currently I have what is attached... Comments?
> > 
> > Looks good to me, want me to queue it up through my char/misc driver
> > tree for 3.11?
> 
> If there are no objections... Whoever picks that up, I would be happy 8-).

I've taken it, without the chipidea portion, through my driver-core
tree.

thanks,

greg k-h

Re: [PATCH] build some drivers only when compile-testing

[Jiri Slaby]

On 06/25/2013 01:42 AM, Greg Kroah-Hartman wrote:
> On Wed, Jun 19, 2013 at 08:50:08AM +0200, Jiri Slaby wrote:
>> On 06/18/2013 06:04 PM, Greg Kroah-Hartman wrote:
>>>> So currently I have what is attached... Comments?
>>>
>>> Looks good to me, want me to queue it up through my char/misc driver
>>> tree for 3.11?
>>
>> If there are no objections... Whoever picks that up, I would be happy 8-).
> 
> I've taken it, without the chipidea portion, through my driver-core
> tree.

Ok thanks. (FWIW I sent v3 without the chipidea change too...)

-- 
js
suse labs

Re: [PATCH] build some drivers only when compile-testing

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 446 bytes --]

On 17/06/13 23:05, Jiri Slaby wrote:

> The last point I inclined to the Greg's argument to remove the EXPERT
> dependency.
> 
> So currently I have what is attached... Comments?

The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're not
adding COMPILE_TEST there, but you're adding a totally new config
option, and also changing the Makefile.

Maybe that's ok, but there's no mention about this in the desc.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Jiri Slaby]

On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
> On 17/06/13 23:05, Jiri Slaby wrote:
> 
>> The last point I inclined to the Greg's argument to remove the
>> EXPERT dependency.
>> 
>> So currently I have what is attached... Comments?
> 
> The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're
> not adding COMPILE_TEST there, but you're adding a totally new
> config option, and also changing the Makefile.

Look:

+config USB_CHIPIDEA_IMX
+       bool "ChipIdea IMX support"
+       depends on OF_DEVICE && (ARM || COMPILE_TEST)

COMPILE_TEST added here ----------------^^^^^^^^^^^^

-- 
js
suse labs

Re: [PATCH] build some drivers only when compile-testing

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1040 bytes --]

On 19/06/13 10:12, Jiri Slaby wrote:
> On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
>> On 17/06/13 23:05, Jiri Slaby wrote:
>>
>>> The last point I inclined to the Greg's argument to remove the
>>> EXPERT dependency.
>>>
>>> So currently I have what is attached... Comments?
>>
>> The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're
>> not adding COMPILE_TEST there, but you're adding a totally new
>> config option, and also changing the Makefile.
> 
> Look:
> 
> +config USB_CHIPIDEA_IMX
> +       bool "ChipIdea IMX support"
> +       depends on OF_DEVICE && (ARM || COMPILE_TEST)
> 
> COMPILE_TEST added here ----------------^^^^^^^^^^^^

My point was that you're not adding COMPILE_TEST to an existing config
option, you're creating a totally new config option.

As I said, that's probably ok, but it'd be nice to mention extra things
like that in the desc. The pedantic approach would be to do the makefile
and Kconfig change in an earlier patch, and then add only COMPILE_TEST.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Greg Kroah-Hartman]

On Wed, Jun 19, 2013 at 09:12:56AM +0200, Jiri Slaby wrote:
> On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
> > On 17/06/13 23:05, Jiri Slaby wrote:
> > 
> >> The last point I inclined to the Greg's argument to remove the
> >> EXPERT dependency.
> >> 
> >> So currently I have what is attached... Comments?
> > 
> > The patch looks a bit odd with the USB_CHIPIDEA_IMX parts. You're
> > not adding COMPILE_TEST there, but you're adding a totally new
> > config option, and also changing the Makefile.
> 
> Look:
> 
> +config USB_CHIPIDEA_IMX
> +       bool "ChipIdea IMX support"
> +       depends on OF_DEVICE && (ARM || COMPILE_TEST)

Ah, what about all of the chipidea chips on x86 boxes (yes, they are
rare, but they are present, so you can't just turn them off for that
whole platform here.

I'd leave chipidea alone, it's getting more prelevant, not on a desktop
or server, but in SoC systems, which is x86 for a lot of devices.

thanks,

greg k-h

Re: [PATCH] build some drivers only when compile-testing

[Ben Hutchings]

[-- Attachment #1: Type: text/plain, Size: 4308 bytes --]

On Wed, 2013-05-22 at 19:23 -0700, Greg Kroah-Hartman wrote:
> On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> > Some drivers can be built on more platforms than they run on. This
> > causes users and distributors packaging burden when they have to
> > manually deselect some drivers from their allmodconfigs. Or sometimes
> > it is even impossible to disable the drivers without patching the
> > kernel.
> > 
> > Introduce a new config option COMPILE_TEST and make all those drivers
> > to depend on the platform they run on, or on the COMPILE_TEST option.
> > Now, when users/distributors choose COMPILE_TEST=n they will not have
> > the drivers in their allmodconfig setups, but developers still can
> > compile-test them with COMPILE_TEST=y.
> 
> I understand the urge, and it's getting hard for distros to handle these
> drivers that just don't work on other architectures, but it's really
> valuable to ensure that they build properly, for those of us that don't
> have many/any cross compilers set up.
> 
> > Now the drivers where we use this new option:
> > * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
> >   processors so it should depend on x86.
> > * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
> > * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
> >   systems -- which do not actually support the hardware via that
> >   method.
> 
> This seems ripe to start to get really messy, really quickly.  Shouldn't
> "default configs" handle if this "should" be enabled for a platform or
> not, and let the rest of us just build them with no problems?

Debian aims to provide a consistent feature set across all supported
architectures so far as possible, and I would expect other distributions
to do the same.  I don't believe anyone is coordinating defconfigs
across architectures to ensure that.

Distributions may also have particular requirements from userland that a
distribution-agnostic defconfig obviously doesn't cover.  (Isn't that
why we had the discussion about 'configure for my distribution' some
months back?)

For the driver configuration, what we provide in Debian is closer to
allmodconfig, only with some attempt to exclude those useless drivers.
Dependencies like this would make it easier to do that.

> What problems is this causing you?  Are you running out of space in
> kernel packages with drivers that will never be actually used?

On most x86 systems this isn't going to be an issue.  But if packages
are built natively (as they are for most distributions) then building
useless drivers for some architecture which doesn't have fast processors
available is a waste of precious resources.

This is particularly bad where the architecture doesn't support generic
kernels that boot on a wide range of machines and therefore we must
build many times over.  These unfortunately tend to be among those with
slower processors (ARM[1], MIPS, SH, ...).  Currently, Debian's linux
package takes ~48 hours to build for armel (ARM processors without FPU)
- and that's without building many of the PCI drivers we could for those
platforms which have PCI support.  So that's a minimum of 2 days to
provide a security update across all architectures[2].

[1] I'm aware that ARM is getting better in this regard and most ARMv7
machines are likely to be supportable by a single kernel image soon.
That doesn't mean the whole problem is solved.

[2] We don't always wait for all builds before releasing/announcing an
update; for example <http://www.debian.org/security/2013/dsa-2669>.  But
that's no comfort for those using the slower architecture.

> > +config COMPILE_TEST
> > +     bool "Compile also drivers which will not load" if EXPERT
> 
> EXPERT is getting to be the "let's hide it here" option, isn't it...

This little detail seems likely to reduce the usefulness of randconfig
as many drivers will become dependent on both EXPERT and COMPILE_TEST
being selected.

> I don't know, if no one else strongly objects, I can be convinced that
> this is needed, but so far, I don't see why it really is, or what this
> is going to help with.

Ben.

-- 
Ben Hutchings
friends: People who know you well, but like you anyway.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

Re: [PATCH] build some drivers only when compile-testing

[Rob Landley]

On 05/23/2013 09:01:40 AM, Ben Hutchings wrote:
> On Wed, 2013-05-22 at 19:23 -0700, Greg Kroah-Hartman wrote:
> > On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
> > > Some drivers can be built on more platforms than they run on. This
> > > causes users and distributors packaging burden when they have to
> > > manually deselect some drivers from their allmodconfigs. Or  
> sometimes
> > > it is even impossible to disable the drivers without patching the
> > > kernel.
> > >
> > > Introduce a new config option COMPILE_TEST and make all those  
> drivers
> > > to depend on the platform they run on, or on the COMPILE_TEST  
> option.
> > > Now, when users/distributors choose COMPILE_TEST=n they will not  
> have
> > > the drivers in their allmodconfig setups, but developers still can
> > > compile-test them with COMPILE_TEST=y.
> >
> > I understand the urge, and it's getting hard for distros to handle  
> these
> > drivers that just don't work on other architectures, but it's really
> > valuable to ensure that they build properly, for those of us that  
> don't
> > have many/any cross compilers set up.

In http://landley.net/aboriginal/bin grab the cross-compiler-*.tar.bz2  
tarballs, extract them, add the "bin" subdirectory of each to the  
$PATH. Congratulations, you have cross compilers set up. (They're  
statically linked and relocatable, so should run just about anywhere.  
If they don't, let me know and I'll fix it.)

Example build:

   make ARCH=sparc sparc32_defconfig
   PATH=/home/landley/simple-cross-compiler-sparc/bin:$PATH \
     make ARCH=sparc CROSS_COMPILE=sparc-

Rob

Re: [PATCH] build some drivers only when compile-testing

[Tomi Valkeinen]

[-- Attachment #1: Type: text/plain, Size: 1355 bytes --]

Hi,

On 22/05/13 12:18, Jiri Slaby wrote:
> Some drivers can be built on more platforms than they run on. This
> causes users and distributors packaging burden when they have to
> manually deselect some drivers from their allmodconfigs. Or sometimes
> it is even impossible to disable the drivers without patching the
> kernel.
> 
> Introduce a new config option COMPILE_TEST and make all those drivers
> to depend on the platform they run on, or on the COMPILE_TEST option.
> Now, when users/distributors choose COMPILE_TEST=n they will not have
> the drivers in their allmodconfig setups, but developers still can
> compile-test them with COMPILE_TEST=y.
> 
> Now the drivers where we use this new option:
> * PTP_1588_CLOCK_PCH: The PCH EG20T is only compatible with Intel Atom
>   processors so it should depend on x86.
> * FB_GEODE: Geode is 32-bit only so only enable it for X86_32.
> * USB_CHIPIDEA_IMX: The OF_DEVICE dependency will be met on powerpc
>   systems -- which do not actually support the hardware via that
>   method.

I had this exact same idea some time ago. The mail below contains some
of my reasoning for this:

http://comments.gmane.org/gmane.linux.kbuild.devel/9829

I proposed a new Kconfig keyword, but Sam was quite against it as the
Kconfig language already does what is required.

 Tomi



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]