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
From: Jeff Mahoney <hidden> Date: 2013-05-23 03:09:54
On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
quoted
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.
quoted
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.
quoted
+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
From: Ben Hutchings <hidden> Date: 2013-05-23 14:02:06
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:
quoted
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.
quoted
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.
quoted
+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.
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
quoted
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?
quoted
quoted
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.
quoted
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.
quoted
quoted
+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
From: Michal Marek <hidden> Date: 2013-06-18 04:51:41
Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
quoted
On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
quoted
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
quoted
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?
quoted
quoted
quoted
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.
quoted
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.
quoted
quoted
quoted
+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
From: Felipe Balbi <hidden> Date: 2013-06-18 08:21:14
Hi,
On Tue, Jun 18, 2013 at 06:51:32AM +0200, Michal Marek wrote:
Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
quoted
On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
quoted
On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
quoted
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
quoted
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?
quoted
quoted
quoted
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.
quoted
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.
quoted
quoted
quoted
+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
Hi,
On Tue, Jun 18, 2013 at 06:51:32AM +0200, Michal Marek wrote:
quoted
Dne 17.6.2013 22:05, Jiri Slaby napsal(a):
quoted
On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
quoted
On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
quoted
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby
wrote:
quoted
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?
quoted
quoted
quoted
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.
quoted
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.
quoted
quoted
quoted
+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
From: Felipe Balbi <hidden> Date: 2013-06-18 08:36:35
Hi,
On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
quoted
quoted
quoted
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
From: Tomi Valkeinen <hidden> Date: 2013-06-18 08:36:55
On 18/06/13 07:51, Michal Marek wrote:
quoted
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
From: Michal Marek <hidden> Date: 2013-06-18 08:45:03
Dne 18.6.2013 10:34, Felipe Balbi napsal(a):
Hi,
On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
quoted
quoted
quoted
quoted
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
From: Felipe Balbi <hidden> Date: 2013-06-18 08:55:00
Hi,
On Tue, Jun 18, 2013 at 10:44:52AM +0200, Michal Marek wrote:
quoted
On Tue, Jun 18, 2013 at 10:24:40AM +0200, Jiri Slaby wrote:
quoted
quoted
quoted
quoted
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
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
On Mon, Jun 17, 2013 at 10:05:19PM +0200, Jiri Slaby wrote:
On 05/23/2013 05:09 AM, Jeff Mahoney wrote:
quoted
On 5/22/13 10:23 PM, Greg Kroah-Hartman wrote:
quoted
On Wed, May 22, 2013 at 11:18:46AM +0200, Jiri Slaby wrote:
quoted
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?
quoted
quoted
quoted
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.
quoted
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.
quoted
quoted
quoted
+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
From: Tomi Valkeinen <hidden> Date: 2013-06-19 07:11:24
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
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.
From: Tomi Valkeinen <hidden> Date: 2013-06-19 07:20:51
On 19/06/13 10:12, Jiri Slaby wrote:
On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
quoted
On 17/06/13 23:05, Jiri Slaby wrote:
quoted
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
On Wed, Jun 19, 2013 at 09:12:56AM +0200, Jiri Slaby wrote:
On 06/19/2013 09:10 AM, Tomi Valkeinen wrote:
quoted
On 17/06/13 23:05, Jiri Slaby wrote:
quoted
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.
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
From: Mark Brown <broonie@kernel.org> Date: 2013-06-19 16:38:34
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.