Hi Andrew,
I think the following isn't on purpose but the IBM Thinkpad acpi
extras default to y in Kconfig. The patch below fixes it:
Signed-off-by: <[email protected]>
--- drivers/acpi/Kconfig.orig 2005-09-09 09:46:26.000000000 +0200
+++ drivers/acpi/Kconfig 2005-09-09 09:46:46.000000000 +0200
@@ -197,7 +197,7 @@ config ACPI_ASUS
config ACPI_IBM
tristate "IBM ThinkPad Laptop Extras"
depends on X86
- default y
+ default n
---help---
This is a Linux ACPI driver for the IBM ThinkPad laptops. It adds
support for Fn-Fx key combinations, Bluetooth control, video
>Hi Andrew,
>
> I think the following isn't on purpose but the IBM Thinkpad acpi
> extras default to y in Kconfig. The patch below fixes it:
>
> Signed-off-by: <[email protected]>
>
>
>--- drivers/acpi/Kconfig.orig 2005-09-09 09:46:26.000000000 +0200
>+++ drivers/acpi/Kconfig 2005-09-09 09:46:46.000000000 +0200
>@@ -197,7 +197,7 @@ config ACPI_ASUS
> config ACPI_IBM
> tristate "IBM ThinkPad Laptop Extras"
> depends on X86
>- default y
>+ default n
> ---help---
> This is a Linux ACPI driver for the IBM ThinkPad
Before we had "default m", since that is how a distro
is expected to compile this, and other, "ACPI drivers".
But we got complaits that _nothing_ should be "default m",
so I changed it to "default y". Maybe that was simplistic --
button should be "default y", but the platform drivers should
all be "default n"?
I'm not sure what to do here -- what use-model
should we tune default Kconfig for?
thanks,
-Len
Hi,
On Fri, 9 Sep 2005, Brown, Len wrote:
> >--- drivers/acpi/Kconfig.orig 2005-09-09 09:46:26.000000000 +0200
> >+++ drivers/acpi/Kconfig 2005-09-09 09:46:46.000000000 +0200
> >@@ -197,7 +197,7 @@ config ACPI_ASUS
> > config ACPI_IBM
> > tristate "IBM ThinkPad Laptop Extras"
> > depends on X86
> >- default y
> >+ default n
> > ---help---
> > This is a Linux ACPI driver for the IBM ThinkPad
>
> Before we had "default m", since that is how a distro
> is expected to compile this, and other, "ACPI drivers".
>
> But we got complaits that _nothing_ should be "default m",
> so I changed it to "default y". Maybe that was simplistic --
> button should be "default y", but the platform drivers should
> all be "default n"?
>
> I'm not sure what to do here -- what use-model
> should we tune default Kconfig for?
The best would be to avoid using defaults completely, unless the resulting
kernel is non-functional (e.g. it doesn't compile or boot).
So far it's still the responsibility of the user to explicitly turn
everything on he needs (at least until we have a functional autoconfig).
BTW distros are not the only users, from them I would expect how to
configure a kernel.
bye, Roman
On Friday 09 September 2005 18:06, Brown, Len wrote:
> I'm not sure what to do here -- what use-model
> should we tune default Kconfig for?
I would just give no default for the platform drivers. They are not
exactly mission critical. The default stuff is for more for
optons that prevent booting when commonly set wrong etc.
-Andi
On Fri, Sep 09, 2005 at 06:25:00PM +0200, Roman Zippel wrote:
> The best would be to avoid using defaults completely, unless the resulting
> kernel is non-functional (e.g. it doesn't compile or boot).
> So far it's still the responsibility of the user to explicitly turn
> everything on he needs (at least until we have a functional autoconfig).
> BTW distros are not the only users, from them I would expect how to
> configure a kernel.
Actually, this sounds pretty sane and IMHO is somehow the biggest common
denominator concerning linux users and their kernel configuration
recreational activities :); but seriously, going all over the menus of Kbuild
and turning everything off is a lot of work compared to turning on the
several things I need on my system. "default m" is also not a good thing
since compiling of unnecessary modules is simply dumb for a system
that's just not going to use them.
Regards,
Boris.
On Sat, 2005-09-10 at 11:42 +0200, Borislav Petkov wrote:
> On Fri, Sep 09, 2005 at 06:25:00PM +0200, Roman Zippel wrote:
>
> > The best would be to avoid using defaults completely, unless the resulting
> > kernel is non-functional (e.g. it doesn't compile or boot).
> > So far it's still the responsibility of the user to explicitly turn
> > everything on he needs (at least until we have a functional autoconfig).
> > BTW distros are not the only users, from them I would expect how to
> > configure a kernel.
>
> Actually, this sounds pretty sane and IMHO is somehow the biggest common
> denominator concerning linux users and their kernel configuration
> recreational activities :); but seriously, going all over the menus of Kbuild
> and turning everything off is a lot of work compared to turning on the
> several things I need on my system. "default m" is also not a good thing
> since compiling of unnecessary modules is simply dumb for a system
> that's just not going to use them.
Not to mention the bugs you get for free while you don't even (actively)
use the offending module/piece of code.
On Saturday 10 September 2005 11:42, Borislav Petkov wrote:
> On Fri, Sep 09, 2005 at 06:25:00PM +0200, Roman Zippel wrote:
> > The best would be to avoid using defaults completely, unless the
> > resulting kernel is non-functional (e.g. it doesn't compile or boot).
> > So far it's still the responsibility of the user to explicitly turn
> > everything on he needs (at least until we have a functional autoconfig).
> > BTW distros are not the only users, from them I would expect how to
> > configure a kernel.
>
> Actually, this sounds pretty sane and IMHO is somehow the biggest common
> denominator concerning linux users and their kernel configuration
> recreational activities :); but seriously, going all over the menus of
> Kbuild and turning everything off is a lot of work compared to turning on
> the several things I need on my system. "default m" is also not a good
> thing since compiling of unnecessary modules is simply dumb for a system
> that's just not going to use them.
The new driver dcdbas driver in -git9 seems to have inherited that bad habit
too. Grr ... Patch appended.
Roman - can you perhaps just forbod default m in Kconfig? I don't think it
makes any sense.
-Andi
Don't set dcdbas driver to default m
It's nasty to set random drivers to default m because people
who just press enter on make oldconfig get these.
Remove the default m
Signed-off-by: Andi Kleen <[email protected]>
Index: linux/drivers/firmware/Kconfig
===================================================================
--- linux.orig/drivers/firmware/Kconfig
+++ linux/drivers/firmware/Kconfig
@@ -71,7 +71,6 @@ config DELL_RBU
config DCDBAS
tristate "Dell Systems Management Base Driver"
depends on X86 || X86_64
- default m
help
The Dell Systems Management Base Driver provides a sysfs interface
for systems management software to perform System Management