LinuxLists.cc - [PATCH] build some drivers only when compile-testing

[permalink] [raw]

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

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

2013-05-23 03:09:54

by Jeff Mahoney

[permalink] [raw]

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

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

2013-05-23 07:48:18

[permalink] [raw]

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

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

Attachments:

2013-05-23 14:02:06

by Ben Hutchings

[permalink] [raw]

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

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.

Attachments:

signature.asc (828.00 B)
This is a digitally signed message part

2013-05-24 04:50:36

by Rob Landley

[permalink] [raw]

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

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-

2013-06-17 20:05:27

[permalink] [raw]

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

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

Attachments:

0001-build-some-drivers-only-when-compile-testing.patch (5.21 kB)

2013-06-18 04:51:41

by Michal Marek

[permalink] [raw]

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

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

2013-06-18 08:21:14

by Felipe Balbi

[permalink] [raw]

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

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

Attachments:

(No filename) (4.30 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2013-06-18 08:24:50

[permalink] [raw]

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

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

2013-06-18 08:36:35

by Felipe Balbi

[permalink] [raw]

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

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

Attachments:

(No filename) (1.65 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2013-06-18 08:36:55

[permalink] [raw]

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

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

Attachments:

2013-06-18 08:45:03

by Michal Marek

[permalink] [raw]

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

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

2013-06-18 08:55:00

by Felipe Balbi

[permalink] [raw]

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

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

Attachments:

(No filename) (2.17 kB)
signature.asc (836.00 B)
Digital signature Download all attachments

2013-06-18 09:21:38

[permalink] [raw]

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

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

2013-06-18 16:03:52

[permalink] [raw]

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

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

2013-06-19 06:50:15

[permalink] [raw]

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

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

2013-06-19 07:11:24

[permalink] [raw]

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

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

Attachments:

2013-06-19 07:13:05

[permalink] [raw]

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

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

2013-06-19 07:20:51

[permalink] [raw]

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

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

Attachments:

2013-06-19 14:26:53

[permalink] [raw]

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

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

2013-06-19 16:38:34

by Mark Brown

[permalink] [raw]

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

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.

Attachments:

(No filename) (883.00 B)
signature.asc (836.00 B)
Digital signature Download all attachments

2013-06-21 18:57:32

[permalink] [raw]

Subject: [PATCH v3] 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
read Kconfig help texts and 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 really run on, or on the COMPILE_TEST
option. Now, when users/distributors choose COMPILE_TEST=n they will
not have the drivers in their oldconfig output, 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.
* INTEL_MID_PTI: It is specific to the Penwell type of Intel Atom
device.

[v2]
* remove EXPERT dependency

[v3]
* do not touch IMX

Signed-off-by: Jiri Slaby <[email protected]>
Cc: Andrew Morton <[email protected]>
Cc: Linus Torvalds <[email protected]>
Cc: Jeff Mahoney <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: Florian Tobias Schandinat <[email protected]>
Cc: [email protected]
Cc: [email protected]
Cc: Richard Cochran <[email protected]>
Cc: [email protected]
Cc: Ben Hutchings <[email protected]>
Cc: "Keller, Jacob E" <[email protected]>
---
drivers/misc/Kconfig | 2 +-
drivers/ptp/Kconfig | 1 +
drivers/video/geode/Kconfig | 2 +-
init/Kconfig | 14 ++++++++++++++
4 files changed, 17 insertions(+), 2 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/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 ce540ef..54d3fa5 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.1

2013-06-24 23:42:43

[permalink] [raw]

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

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

2013-06-25 08:17:04