[2.6 patch] make INPUT a bool

[2.6 patch] make INPUT a bool

[Adrian Bunk]

Make INPUT a bool.

INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
make that much sense to make it modular.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

This patch was already sent on:
- 3 Feb 2006

 drivers/input/Kconfig |    2 +-
 drivers/input/input.c |    8 --------
 2 files changed, 1 insertion(+), 9 deletions(-)

--- linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig.old	2006-02-03 22:42:18.000000000 +0100
+++ linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig	2006-02-03 22:42:29.000000000 +0100
@@ -5,7 +5,7 @@
 menu "Input device support"
 
 config INPUT
-	tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED
+	bool "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED
 	default y
 	---help---
 	  Say Y here if you have any input device (mouse, keyboard, tablet,
--- linux-2.6.16-rc1-mm5-full/drivers/input/input.c.old	2006-02-03 22:42:41.000000000 +0100
+++ linux-2.6.16-rc1-mm5-full/drivers/input/input.c	2006-02-03 22:47:44.000000000 +0100
@@ -984,12 +984,4 @@
 	return err;
 }
 
-static void __exit input_exit(void)
-{
-	input_proc_exit();
-	unregister_chrdev(INPUT_MAJOR, "input");
-	class_unregister(&input_class);
-}
-
 subsys_initcall(input_init);
-module_exit(input_exit);

Re: [2.6 patch] make INPUT a bool

[Jan Engelhardt]

>
>Make INPUT a bool.
>
>INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
>make that much sense to make it modular.
>
modular would make sense to me - http://lkml.org/lkml/2006/1/25/106

>This patch was already sent on:
>- 3 Feb 2006


Jan Engelhardt
-- 

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Tue, Feb 14, 2006 at 07:14:21PM +0100, Jan Engelhardt wrote:
> >
> >Make INPUT a bool.
> >
> >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
> >make that much sense to make it modular.
> >
> modular would make sense to me - http://lkml.org/lkml/2006/1/25/106
>...

I don't get your point:

You don't need INPUT modular for hotplugging devices.

In the normal EMBEDDED=n cases, users already do not have the choice of 
making INPUT modular.

If someone is working in an environment that is that space limited that 
he sets EMBEDDED=y, why on earth should he enable module support that 
uses relatively much space in his kernel?

> Jan Engelhardt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Tue, Feb 14, 2006 at 07:22:38PM +0100, Adrian Bunk wrote:
> On Tue, Feb 14, 2006 at 07:14:21PM +0100, Jan Engelhardt wrote:
> > >
> > >Make INPUT a bool.
> > >
> > >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
> > >make that much sense to make it modular.
> > >
> > modular would make sense to me - http://lkml.org/lkml/2006/1/25/106
> >...
> 
> I don't get your point:
> 
> You don't need INPUT modular for hotplugging devices.
> 
> In the normal EMBEDDED=n cases, users already do not have the choice of 
> making INPUT modular.
> 
> If someone is working in an environment that is that space limited that 
> he sets EMBEDDED=y, why on earth should he enable module support that 
> uses relatively much space in his kernel?
>...

To back this with numbers:

I'm usually using a non-modular kernel on my computer.

This is the size difference between the same kernel with 
CONFIG_MODULES=y and CONFIG_MODULES=n:
  3799589 vmlinux-with-modules
  3447297 vmlinux-without-modules

Yes, the kernel is becoming bigger by 10% only for supporting modules.

Since the size increase is the space for the module support part of the 
kernel plus some additional space in many object files for stuff like 
EXPORT_SYMBOL's, the relative size increase is most likely even bigger 
for small kernels.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Jan Engelhardt]

>> >Make INPUT a bool.
>> >
>> >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
>> >make that much sense to make it modular.
>> >
>> modular would make sense to me - http://lkml.org/lkml/2006/1/25/106
>>...
>
>I don't get your point:
>You don't need INPUT modular for hotplugging devices.

Well that is, if one happens to plug in a, say, USB keyboard.


Jan Engelhardt
-- 

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Fri, Feb 17, 2006 at 04:56:51PM +0100, Jan Engelhardt wrote:
> >> >Make INPUT a bool.
> >> >
> >> >INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
> >> >make that much sense to make it modular.
> >> >
> >> modular would make sense to me - http://lkml.org/lkml/2006/1/25/106
> >>...
> >
> >I don't get your point:
> >You don't need INPUT modular for hotplugging devices.
> 
> Well that is, if one happens to plug in a, say, USB keyboard.


Let me repeat the same sentence more boldly:

YOU DO NOT NEED MODULES FOR HOTPLUGGING DEVICES.

Please try to understand this sentence.


And I've already given numbers why CONFIG_EMBEDDED=y and 
CONFIG_MODULES=y at the same time is insane.


> Jan Engelhardt


cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Samuel Masham]

Hi Adrian,

> And I've already given numbers why CONFIG_EMBEDDED=y and
> CONFIG_MODULES=y at the same time is insane.

>From your numbers this sounds true ... but actually you might want the
modules to delay the init of the various hardware bits...

Sometime boot-time is king and you just try and get back as much of
the size costs as it takes...

I think for EMBEDDED and MODULES is actually a very common case ... if
somewhat odd.

Samuel

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:

> Hi Adrian,

Hi Samuel,

> > And I've already given numbers why CONFIG_EMBEDDED=y and
> > CONFIG_MODULES=y at the same time is insane.
> 
> >From your numbers this sounds true ... but actually you might want the
> modules to delay the init of the various hardware bits...
> 
> Sometime boot-time is king and you just try and get back as much of
> the size costs as it takes...

this is irrelevant since CONFIG_INPUT alone does not init any hardware.

> I think for EMBEDDED and MODULES is actually a very common case ... if
> somewhat odd.

You are misunderstanding EMBEDDED.

It does _not_ mean "this is an embedded device".
It does mean "offer additional options for additional space savings".

For an embedded system with relaxed space limits, EMBEDDED=n is the 
right choice.

> Samuel

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Herbert Poetzl]

On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> 
> > Hi Adrian,
> 
> Hi Samuel,
> 
> > > And I've already given numbers why CONFIG_EMBEDDED=y and
> > > CONFIG_MODULES=y at the same time is insane.
> > 
> > >From your numbers this sounds true ... but actually you might want the
> > modules to delay the init of the various hardware bits...
> > 
> > Sometime boot-time is king and you just try and get back as much of
> > the size costs as it takes...
> 
> this is irrelevant since CONFIG_INPUT alone does not init any hardware.
> 
> > I think for EMBEDDED and MODULES is actually a very common case ... if
> > somewhat odd.
> 
> You are misunderstanding EMBEDDED.

well, I suggested the following (or a similar)
change some time ago (unfortunately I could not
find it in the lkml archives, so it might have
been lost)

http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt

best,
Herbert

> It does _not_ mean "this is an embedded device".
> It does mean "offer additional options for additional space savings".
> 
> For an embedded system with relaxed space limits, EMBEDDED=n is the 
> right choice.
> 
> > Samuel
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote:
> On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> > 
> > > Hi Adrian,
> > 
> > Hi Samuel,
> > 
> > > > And I've already given numbers why CONFIG_EMBEDDED=y and
> > > > CONFIG_MODULES=y at the same time is insane.
> > > 
> > > >From your numbers this sounds true ... but actually you might want the
> > > modules to delay the init of the various hardware bits...
> > > 
> > > Sometime boot-time is king and you just try and get back as much of
> > > the size costs as it takes...
> > 
> > this is irrelevant since CONFIG_INPUT alone does not init any hardware.
> > 
> > > I think for EMBEDDED and MODULES is actually a very common case ... if
> > > somewhat odd.
> > 
> > You are misunderstanding EMBEDDED.
> 
> well, I suggested the following (or a similar)
> change some time ago (unfortunately I could not
> find it in the lkml archives, so it might have
> been lost)
> 
> http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt

That's not a good solution since EMBEDDED is really only about 
additional space savings - even if you are an "expert", there's no 
reason to enable EMBEDDED when building a kernel for systems 
with > 50 MB RAM.

The better solution is IMHO an additional option:
  http://lkml.org/lkml/2006/2/7/93
  http://lkml.org/lkml/2006/2/7/139

> best,
> Herbert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Herbert Poetzl]

On Wed, Feb 22, 2006 at 03:31:21AM +0100, Adrian Bunk wrote:
> On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote:
> > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> > > 
> > > > Hi Adrian,
> > > 
> > > Hi Samuel,
> > > 
> > > > > And I've already given numbers why CONFIG_EMBEDDED=y and
> > > > > CONFIG_MODULES=y at the same time is insane.
> > > > 
> > > > >From your numbers this sounds true ... but actually you might want the
> > > > modules to delay the init of the various hardware bits...
> > > > 
> > > > Sometime boot-time is king and you just try and get back as much of
> > > > the size costs as it takes...
> > > 
> > > this is irrelevant since CONFIG_INPUT alone does not init any hardware.
> > > 
> > > > I think for EMBEDDED and MODULES is actually a very common case ... if
> > > > somewhat odd.
> > > 
> > > You are misunderstanding EMBEDDED.
> > 
> > well, I suggested the following (or a similar)
> > change some time ago (unfortunately I could not
> > find it in the lkml archives, so it might have
> > been lost)
> > 
> > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt
> 
> That's not a good solution since EMBEDDED is really only about 
> additional space savings - even if you are an "expert", there's no 
> reason to enable EMBEDDED when building a kernel for systems 
> with > 50 MB RAM.

well, not sure everybody kows that ...

 config X86_P4_CLOCKMOD
	depends on EMBEDDED

 config VT_CONSOLE
	bool "Support for console on virtual terminal" if EMBEDDED

 config VGA_CONSOLE
	bool "VGA text console" if EMBEDDED 

 config DNOTIFY
	bool "Dnotify support" if EMBEDDED

 config DEBUG_BUGVERBOSE
	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED

but, the patch was just considered a starting point
so that folks would know _what_ EMBEDDED is currently
used for ...

> The better solution is IMHO an additional option:
>   http://lkml.org/lkml/2006/2/7/93
>   http://lkml.org/lkml/2006/2/7/139

whatever, just get rid of the CONFIG_EMBEDDED everybody
get's wrong and nobody really understands ...

> > best,
> > Herbert
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote:
> On Wed, Feb 22, 2006 at 03:31:21AM +0100, Adrian Bunk wrote:
> > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote:
> > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> > > > 
> > > > > Hi Adrian,
> > > > 
> > > > Hi Samuel,
> > > > 
> > > > > > And I've already given numbers why CONFIG_EMBEDDED=y and
> > > > > > CONFIG_MODULES=y at the same time is insane.
> > > > > 
> > > > > >From your numbers this sounds true ... but actually you might want the
> > > > > modules to delay the init of the various hardware bits...
> > > > > 
> > > > > Sometime boot-time is king and you just try and get back as much of
> > > > > the size costs as it takes...
> > > > 
> > > > this is irrelevant since CONFIG_INPUT alone does not init any hardware.
> > > > 
> > > > > I think for EMBEDDED and MODULES is actually a very common case ... if
> > > > > somewhat odd.
> > > > 
> > > > You are misunderstanding EMBEDDED.
> > > 
> > > well, I suggested the following (or a similar)
> > > change some time ago (unfortunately I could not
> > > find it in the lkml archives, so it might have
> > > been lost)
> > > 
> > > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt
> > 
> > That's not a good solution since EMBEDDED is really only about 
> > additional space savings - even if you are an "expert", there's no 
> > reason to enable EMBEDDED when building a kernel for systems 
> > with > 50 MB RAM.
> 
> well, not sure everybody kows that ...
> 
>  config X86_P4_CLOCKMOD
> 	depends on EMBEDDED

This one is an x86_64 only issue, and yes, it's wrong.

>  config VT_CONSOLE
> 	bool "Support for console on virtual terminal" if EMBEDDED

Looks OK.

>  config VGA_CONSOLE
> 	bool "VGA text console" if EMBEDDED 

Looks OK.

>  config DNOTIFY
> 	bool "Dnotify support" if EMBEDDED

Looks OK.

>  config DEBUG_BUGVERBOSE
> 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED

Looks OK.

> but, the patch was just considered a starting point
> so that folks would know _what_ EMBEDDED is currently
> used for ...

Except for the X86_P4_CLOCKMOD case, all of your examples are correct 
usages of EMBEDDED.

> > The better solution is IMHO an additional option:
> >   http://lkml.org/lkml/2006/2/7/93
> >   http://lkml.org/lkml/2006/2/7/139
> 
> whatever, just get rid of the CONFIG_EMBEDDED everybody
> get's wrong and nobody really understands ...

No, the EMBEDDED semantics shouldn't be changed and most people get it 
right.

Naming it EXPERT as you suggested would make it even worse. We could name it 
SHOW_OPTIONS_FOR_ADDITIONAL_SPACE_SAVINGS_IF_YOU_REALLY_KNOW_WHAT_YOU_ARE_DOING, 
but unless someone comes up with a name that is both short and 
significantely better than EMBEDDED I don't see a reason for changing it.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Dmitry Torokhov]

On Tuesday 21 February 2006 22:10, Adrian Bunk wrote:
> On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote:
> > 
> >  config X86_P4_CLOCKMOD
> > 	depends on EMBEDDED
> 
> This one is an x86_64 only issue, and yes, it's wrong.

That's for P4, not X86_64... And since P4 clock modulation does not provide
almost any energy savings it was "hidden" under embedded.

-- 
Dmitry

Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Tue, Feb 21, 2006 at 10:20:04PM -0500, Dmitry Torokhov wrote:
> On Tuesday 21 February 2006 22:10, Adrian Bunk wrote:
> > On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote:
> > > 
> > >  config X86_P4_CLOCKMOD
> > > 	depends on EMBEDDED
> > 
> > This one is an x86_64 only issue, and yes, it's wrong.
> 
> That's for P4, not X86_64... And since P4 clock modulation does not provide
> almost any energy savings it was "hidden" under embedded.

But the EMBEDDED dependency is only on x86_64:

arch/i386/kernel/cpu/cpufreq/Kconfig:
config X86_P4_CLOCKMOD
        tristate "Intel Pentium 4 clock modulation"
        select CPU_FREQ_TABLE
        help

arch/x86_64/kernel/cpufreq/Kconfig:
config X86_P4_CLOCKMOD
        tristate "Intel Pentium 4 clock modulation"
        depends on EMBEDDED
        help

And if the option is mostly useless, what is it good for?

> Dmitry

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Dave Jones]

On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:

 > > > >  config X86_P4_CLOCKMOD
 > > > > 	depends on EMBEDDED
 > > > 
 > > > This one is an x86_64 only issue, and yes, it's wrong.
 > > 
 > > That's for P4, not X86_64... And since P4 clock modulation does not provide
 > > almost any energy savings it was "hidden" under embedded.
 > 
 > But the EMBEDDED dependency is only on x86_64:
 > 
 > arch/i386/kernel/cpu/cpufreq/Kconfig:
 > config X86_P4_CLOCKMOD
 >         tristate "Intel Pentium 4 clock modulation"
 >         select CPU_FREQ_TABLE
 >         help
 > 
 > arch/x86_64/kernel/cpufreq/Kconfig:
 > config X86_P4_CLOCKMOD
 >         tristate "Intel Pentium 4 clock modulation"
 >         depends on EMBEDDED
 >         help
 > 
 > And if the option is mostly useless, what is it good for?

It's sometimes useful in cases where the target CPU doesn't have any better
option (Speedstep/Powernow).  The big misconception is that it
somehow saves power & increases battery life. Not so.
All it does is 'not do work so often'.  The upside of this is
that in some situations, we generate less heat this way.

It's really of limited practical use, but occasionally, we find
some users that do find it handy.  (One case I heard was someone
with a server farm that generated lots of heat, but at nighttime,
he could throttle that back, which resulted in a drop in overall
temperature in the serverroom -- no numbers to back it up though,
just anecdotes).  

As to the difference of EMBEDDED.. on 32bit, there's a lot more
systems without speedstep/powernow, so it makes more sense to
make it more widely available.  Nearly all AMD64/EM64T have 
some form of speed-scaling which is more effective than p4-clockmod,
which is why I assume it's set that way.

Andi can probably confirm the thinking on that one, as I think
he added it when x86-64 first started supporting cpufreq.

		Dave

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Thursday 23 February 2006 21:41, Dave Jones wrote:

> It's really of limited practical use, but occasionally, we find
> some users that do find it handy.  (One case I heard was someone
> with a server farm that generated lots of heat, but at nighttime,
> he could throttle that back, which resulted in a drop in overall
> temperature in the serverroom -- no numbers to back it up though,
> just anecdotes).

Perhaps they should just turn some computers off over night then.

Another drawback is that adds very long latencies. e.g. when it is
enabled you can really end up with desktops where the mouse
doesn't react for a very visible to humans delay.

And it'll mess up kernel timing in general.

> As to the difference of EMBEDDED.. on 32bit, there's a lot more
> systems without speedstep/powernow, so it makes more sense to
> make it more widely available.  Nearly all AMD64/EM64T have
> some form of speed-scaling which is more effective than p4-clockmod,
> which is why I assume it's set that way.
>
> Andi can probably confirm the thinking on that one, as I think
> he added it when x86-64 first started supporting cpufreq.

It should IMHO depend on EMBEDDED on i386 too because
the uses are extremly specialized (if there are any) and most users setting it 
probably set it by mistake because they misunderstand it.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Fri, Feb 24, 2006 at 12:15:59AM +0100, Andi Kleen wrote:
> On Thursday 23 February 2006 21:41, Dave Jones wrote:
>...
> > As to the difference of EMBEDDED.. on 32bit, there's a lot more
> > systems without speedstep/powernow, so it makes more sense to
> > make it more widely available.  Nearly all AMD64/EM64T have
> > some form of speed-scaling which is more effective than p4-clockmod,
> > which is why I assume it's set that way.
> >
> > Andi can probably confirm the thinking on that one, as I think
> > he added it when x86-64 first started supporting cpufreq.
> 
> It should IMHO depend on EMBEDDED on i386 too because
> the uses are extremly specialized (if there are any) and most users setting it 
> probably set it by mistake because they misunderstand it.

EMBEDDED is the wrong option, since the semantics of embedded is "show 
more options to allow additional space savings". It is not and should 
not be abused as an option to hide random options from users.

Currently, EXPERIMENTAL is nearer to what suits X86_P4_CLOCKMOD, and it 
seems we really need an ADVANCED_USER option for such options.

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Friday 24 February 2006 00:33, Adrian Bunk wrote:

> EMBEDDED is the wrong option, since the semantics of embedded is "show
> more options to allow additional space savings". It is not and should
> not be abused as an option to hide random options from users.

I disagree. And I originally added most EMBEDDED users to the kernel.
The purpose I added it for was to hide options that only useful
for a very limited userbase but cause big or subtle trouble when set
wrong. P4_CLOCKMOD clearly qualifies.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Fri, Feb 24, 2006 at 12:55:30AM +0100, Andi Kleen wrote:
> On Friday 24 February 2006 00:33, Adrian Bunk wrote:
> 
> > EMBEDDED is the wrong option, since the semantics of embedded is "show
> > more options to allow additional space savings". It is not and should
> > not be abused as an option to hide random options from users.
> 
> I disagree. And I originally added most EMBEDDED users to the kernel.
> The purpose I added it for was to hide options that only useful
> for a very limited userbase but cause big or subtle trouble when set
> wrong. P4_CLOCKMOD clearly qualifies.

This matches neither the description of the EMBEDDED option nor all 
other usages in the kernel I have seen until now.

We need an additional option for such cases, but overloading EMBEDDED 
with more than one meaning is definitely not a good idea.

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Friday 24 February 2006 03:39, Adrian Bunk wrote:

> We need an additional option for such cases, but overloading EMBEDDED 
> with more than one meaning is definitely not a good idea.

I think it works just fine.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Fri, Feb 24, 2006 at 03:42:02AM +0100, Andi Kleen wrote:
> On Friday 24 February 2006 03:39, Adrian Bunk wrote:
> 
> > We need an additional option for such cases, but overloading EMBEDDED 
> > with more than one meaning is definitely not a good idea.
> 
> I think it works just fine.

It works in the way that users don't see this option.

Both for this purpose, BROKEN or even simply removing the option would 
work equally well...

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Thu, Feb 23, 2006, Dave Jones wrote:
> On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
>  > And if the option is mostly useless, what is it good for?
> 
> It's sometimes useful in cases where the target CPU doesn't have any better
> option (Speedstep/Powernow).  The big misconception is that it
> somehow saves power & increases battery life. Not so.
> All it does is 'not do work so often'.  The upside of this is
> that in some situations, we generate less heat this way.

Doesn't less heat imply less power consumption?

Anyway, I have P4 in my desktop machine, and the reason
why I tried to use P4 clock modulation was to reduce fan noise,
and save some energy. And yes, fan noise was reduced.

The reason why I turned it off again was that I couldn't
find any governor or userspace daemon that would work
in a sensible way with the high latency of the P4
clock modulation.
What I think could work:

- after some minutes of idling without user activity
  go into lowest power mode (could be triggered
  from xscreensaver)
- at the slightest hint of user activity or CPU load jump
  back to max performance mode
(- optionally use intermediate clock mod steps for
  non-interactive loads, but I'm not convinced it's
  worth it)

P4 clockmod certainly sucks compared to Speedstep,
but IMHO it is still potentially useful for the average
desktop PC user (at least those many who let their PCs
run 24/7, but 90% idle and unused).


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Dave Jones]

On Sat, Feb 25, 2006 at 02:57:22AM +0100, Johannes Stezenbach wrote:
 > On Thu, Feb 23, 2006, Dave Jones wrote:
 > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
 > >  > And if the option is mostly useless, what is it good for?
 > > 
 > > It's sometimes useful in cases where the target CPU doesn't have any better
 > > option (Speedstep/Powernow).  The big misconception is that it
 > > somehow saves power & increases battery life. Not so.
 > > All it does is 'not do work so often'.  The upside of this is
 > > that in some situations, we generate less heat this way.
 > 
 > Doesn't less heat imply less power consumption?

Not really.  The only energy you're saving is that your CPU fan
will turn slightly slower, which is probably going to be < 1W
of difference.  Generated heat drop in a large room of servers
*may* mean the aircon has less to do, but I'd be surprised if
it made a noticable difference.

 > - after some minutes of idling without user activity
 >   go into lowest power mode (could be triggered
 >   from xscreensaver)
 > - at the slightest hint of user activity or CPU load jump
 >   back to max performance mode
 > (- optionally use intermediate clock mod steps for
 >   non-interactive loads, but I'm not convinced it's
 >   worth it)

You should be able to modify cpuspeed or some other userspace
governor to do this quite easily.

		Dave

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Fri, Feb 24, 2006, Dave Jones wrote:
> On Sat, Feb 25, 2006 at 02:57:22AM +0100, Johannes Stezenbach wrote:
>  > On Thu, Feb 23, 2006, Dave Jones wrote:
>  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
>  > >  > And if the option is mostly useless, what is it good for?
>  > > 
>  > > It's sometimes useful in cases where the target CPU doesn't have any better
>  > > option (Speedstep/Powernow).  The big misconception is that it
>  > > somehow saves power & increases battery life. Not so.
>  > > All it does is 'not do work so often'.  The upside of this is
>  > > that in some situations, we generate less heat this way.
>  > 
>  > Doesn't less heat imply less power consumption?
> 
> Not really.  The only energy you're saving is that your CPU fan
> will turn slightly slower, which is probably going to be < 1W
> of difference.

I thought the fan turns slower because the CPU generates
less heat, which in turn is because it consumes less
electrical energy.

If someone has done measurements I'd be interested to
know the numbers about the actual power savings which
can be achieved by using P4 clock mod. I don't expect
it to be much, but I bet it's more than 1W.


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Wes Felter]

Johannes Stezenbach wrote:

> If someone has done measurements I'd be interested to
> know the numbers about the actual power savings which
> can be achieved by using P4 clock mod. I don't expect
> it to be much, but I bet it's more than 1W.

Clock modulation can reduce power by 40W on a 3.6GHz Xeon when the 
system is running a high-power application (e.g. Linpack). (It also 
reduces performance by a factor of 6-10). Clock modulation saves no 
power at all during idle.

Wes Felter - wesley@felter.org

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> On Thu, Feb 23, 2006, Dave Jones wrote:
> > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> >  > And if the option is mostly useless, what is it good for?
> > 
> > It's sometimes useful in cases where the target CPU doesn't have any better
> > option (Speedstep/Powernow).  The big misconception is that it
> > somehow saves power & increases battery life. Not so.
> > All it does is 'not do work so often'.  The upside of this is
> > that in some situations, we generate less heat this way.
> 
> Doesn't less heat imply less power consumption?

Not in this case no.

> P4 clockmod certainly sucks compared to Speedstep,
> but IMHO it is still potentially useful for the average
> desktop PC user (at least those many who let their PCs
> run 24/7, but 90% idle and unused).

I don't think so no. The latencies make it unusable.

-Andi
 

Re: Status of X86_P4_CLOCKMOD?

[Adrian Bunk]

On Sat, Feb 25, 2006 at 05:27:01AM +0100, Andi Kleen wrote:
> On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> > On Thu, Feb 23, 2006, Dave Jones wrote:
> > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> > >  > And if the option is mostly useless, what is it good for?
> > > 
> > > It's sometimes useful in cases where the target CPU doesn't have any better
> > > option (Speedstep/Powernow).  The big misconception is that it
> > > somehow saves power & increases battery life. Not so.
> > > All it does is 'not do work so often'.  The upside of this is
> > > that in some situations, we generate less heat this way.
> > 
> > Doesn't less heat imply less power consumption?
> 
> Not in this case no.
>...

Sorry for the dumb question, but how could this work physically?

If a computer produces less heat with the same power consumption, what 
happens with the other energy?

> -Andi

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

On Sat, Feb 25, 2006 at 01:53:26PM +0100, Adrian Bunk wrote:
> > > Doesn't less heat imply less power consumption?
> > 
> > Not in this case no.
> >...
> 
> Sorry for the dumb question, but how could this work physically?
> 
> If a computer produces less heat with the same power consumption, what 
> happens with the other energy?

No. Let's do the math (again), and (again) for the actual values of an Intel
Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
physics, logic and mathematics apply to _all_ processors.

Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
Power consumption when "skipping instructions"
	because of throttling (Stop-Grant state)	 7.3 W

Power consumption when doing work			22.0 W


This means that if the processor idle percentage is _larger_ than (1 -
throttling rate), throttling has no effect at all.


Now, let's assume there is some work for the CPU to do which keeps it busy
for one second @ 1.4 GHz. How much energy is needed to get this work done?

0% throttling:		22 Ws	(1s)
25% throttling:		24 Ws	(1.3s)
50% throttling:		29 Ws	(2s)
75% throttling:		44 Ws	(4s)


Now let's also assume there is nothing else to do during a span of four
seconds: then, independent of the throttling setting, the CPU power
consumption is 44 Ws for these four seconds.


However: for the 75% throttling state, the CPU only produces 11 W of heat
_all the time_ -- this means, the fan or air conditioning must only consider
11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
that sufficiently, the fan _may_ need to run faster, which consumes more
energy than is saved by only having to cool 7.3 W (instead of 11W) the other
three seconds.


So: P4-clockmod style throttling only makes sense if either

a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or

b) the load varies significantly over time in a manner which has effect on
   the fan, and where the latency induced by throttling doesn't matter.


	Dominik

Re: Status of X86_P4_CLOCKMOD?

[Pavel Machek]

Hi!

> > > Not in this case no.
> > >...
> > 
> > Sorry for the dumb question, but how could this work physically?
> > 
> > If a computer produces less heat with the same power consumption, what 
> > happens with the other energy?
> 
> No. Let's do the math (again), and (again) for the actual values of an Intel
> Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
> physics, logic and mathematics apply to _all_ processors.
> 
> Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
> Power consumption when "skipping instructions"
> 	because of throttling (Stop-Grant state)	 7.3 W
> 
> Power consumption when doing work			22.0 W
> 
> 
> This means that if the processor idle percentage is _larger_ than (1 -
> throttling rate), throttling has no effect at all.
> 
> 
> Now, let's assume there is some work for the CPU to do which keeps it busy
> for one second @ 1.4 GHz. How much energy is needed to get this work done?
> 
> 0% throttling:		22 Ws	(1s)
> 25% throttling:		24 Ws	(1.3s)
> 50% throttling:		29 Ws	(2s)
> 75% throttling:		44 Ws	(4s)
> 
> 
> Now let's also assume there is nothing else to do during a span of four
> seconds: then, independent of the throttling setting, the CPU power
> consumption is 44 Ws for these four seconds.
> 
> 
> However: for the 75% throttling state, the CPU only produces 11 W of heat
> _all the time_ -- this means, the fan or air conditioning must only consider
> 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
> that sufficiently, the fan _may_ need to run faster, which consumes more
> energy than is saved by only having to cool 7.3 W (instead of 11W) the other
> three seconds.
> 
> 
> So: P4-clockmod style throttling only makes sense if either
> 
> a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> 
> b) the load varies significantly over time in a manner which has effect on
>    the fan, and where the latency induced by throttling doesn't matter.

c) your load is something like game of doom, where you want
  to play for half an hour with least power consumed. You
  don't really need 1000 fps, 100 fps is enough.
						Pavel
-- 
Thanks, Sharp!

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Sat, Feb 25, 2006 at, Dominik Brodowski wrote:
> On Sat, Feb 25, 2006 at 01:53:26PM +0100, Adrian Bunk wrote:
> > > > Doesn't less heat imply less power consumption?
> > > 
> > > Not in this case no.
> > >...
> > 
> > Sorry for the dumb question, but how could this work physically?
> > 
> > If a computer produces less heat with the same power consumption, what 
> > happens with the other energy?
> 
> No. Let's do the math (again), and (again) for the actual values of an Intel
> Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
> physics, logic and mathematics apply to _all_ processors.

Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find
anything substantial with google.) Especially C2 vs. C2 + throttling?
Because the way I remember having read somewhere, the idle
(C2) power consumption of the P4 is significantly higher
than with the Pentium(R) M.

> Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
> Power consumption when "skipping instructions"
> 	because of throttling (Stop-Grant state)	 7.3 W
> 
> Power consumption when doing work			22.0 W
> 
> 
> This means that if the processor idle percentage is _larger_ than (1 -
> throttling rate), throttling has no effect at all.

On a Pentium(R) M, but how about P4? The two have very different
architectures, don't they?

> Now, let's assume there is some work for the CPU to do which keeps it busy
> for one second @ 1.4 GHz. How much energy is needed to get this work done?
> 
> 0% throttling:		22 Ws	(1s)
> 25% throttling:		24 Ws	(1.3s)
> 50% throttling:		29 Ws	(2s)
> 75% throttling:		44 Ws	(4s)
> 
> 
> Now let's also assume there is nothing else to do during a span of four
> seconds: then, independent of the throttling setting, the CPU power
> consumption is 44 Ws for these four seconds.
> 
> 
> However: for the 75% throttling state, the CPU only produces 11 W of heat
> _all the time_ -- this means, the fan or air conditioning must only consider
> 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
> that sufficiently, the fan _may_ need to run faster, which consumes more
> energy than is saved by only having to cool 7.3 W (instead of 11W) the other
> three seconds.

This is all fine, but why would anyone use throttling when the
CPU has work to do (except for thermal emergency throttling)?

> So: P4-clockmod style throttling only makes sense if either
> 
> a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> 
> b) the load varies significantly over time in a manner which has effect on
>    the fan, and where the latency induced by throttling doesn't matter.

Maybe my previous mails were not clear enough: The goal is to
reduce idle power consumption (and by that fan noise). The PC
is running but is idle, e.g just listening for possible incoming
jabber messages or whatever.

When I experimented with P4-clockmod some time ago, I observed
that the fan noise was reduced when I left the box run idle
with clockmod set to maximum throttling. I thought this was
a good thing.

Anyway, 2.6.16-rc4 p4-clockmod driver doesn't work with my CPU
anymore (booted with cpufreq.debug=7):

CPU: Intel(R) Pentium(R) 4 CPU 2.60GHz stepping 09
Checking 'hlt' instruction... OK.
...
cpufreq-core: trying to register driver p4-clockmod
cpufreq-core: adding CPU 0
p4-clockmod: has errata -- disabling frequencies lower than 2ghz
speedstep-lib: x86: f, model: 2
speedstep-lib: ebx value is 9, x86_mask is 9
speedstep-lib: P4 - MSR_EBC_FREQUENCY_ID: 0xd12000d 0x0
speedstep-lib: P4 - FSB 200000 kHz; Multiplier 13; Speed 2600000 kHz
freq-table: setting show_table for cpu 0 to b04be620
freq-table: table entry 0 is invalid, skipping
freq-table: table entry 1 is invalid, skipping
freq-table: table entry 2 is invalid, skipping
freq-table: table entry 3 is invalid, skipping
freq-table: table entry 4 is invalid, skipping
freq-table: table entry 5 is invalid, skipping
freq-table: table entry 6 is invalid, skipping
freq-table: table entry 7 is invalid, skipping
freq-table: table entry 8 is invalid, skipping
cpufreq-core: initialization failed
cpufreq-core: no CPU initialized for driver p4-clockmod
cpufreq-core: unregistering CPU 0


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

Hi,

On Sun, Feb 26, 2006 at 09:39:41PM +0100, Johannes Stezenbach wrote:
> > No. Let's do the math (again), and (again) for the actual values of an Intel
> > Pentium(R) M Processor, 1400 MHz @ 1.484 V, even though the same rules of
> > physics, logic and mathematics apply to _all_ processors.
> 
> Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find
> anything substantial with google.) Especially C2 vs. C2 + throttling?
> Because the way I remember having read somewhere, the idle
> (C2) power consumption of the P4 is significantly higher
> than with the Pentium(R) M.

Unfortunately, I do not have these numbers present. You can check the
processor specification sheets at Intel's website, though.


> > Power consumption in idle state C2 (Stop-Grant state)	 7.3 W
> > Power consumption when "skipping instructions"
> > 	because of throttling (Stop-Grant state)	 7.3 W
> > 
> > Power consumption when doing work			22.0 W
> > 
> > 
> > This means that if the processor idle percentage is _larger_ than (1 -
> > throttling rate), throttling has no effect at all.
> 
> On a Pentium(R) M, but how about P4? The two have very different
> architectures, don't they?

They have different architectures, but again -- AFAIK -- throttling means STPCLK
is stopped, which is equivalent to the Stop-Grant state. And that's what's
usually entered in C2-type idle sleep.

> > However: for the 75% throttling state, the CPU only produces 11 W of heat
> > _all the time_ -- this means, the fan or air conditioning must only consider
> > 11 W. For 0%, the CPU may produce 44 W of heat in a second -- and to cool
> > that sufficiently, the fan _may_ need to run faster, which consumes more
> > energy than is saved by only having to cool 7.3 W (instead of 11W) the other
> > three seconds.
> 
> This is all fine, but why would anyone use throttling when the
> CPU has work to do (except for thermal emergency throttling)?

That's exactly the opposite of what you should do, if idling works at least
reasonably well: only enter throttling if the CPU has some substancial
workload.

> > So: P4-clockmod style throttling only makes sense if either
> > 
> > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> > 
> > b) the load varies significantly over time in a manner which has effect on
> >    the fan, and where the latency induced by throttling doesn't matter.
> 
> Maybe my previous mails were not clear enough: The goal is to
> reduce idle power consumption (and by that fan noise). The PC
> is running but is idle, e.g just listening for possible incoming
> jabber messages or whatever.

Most probably, the idle handler can't make use of the Stop-Grant state (C2)
here, so this is case a) noted above.

> p4-clockmod: has errata -- disabling frequencies lower than 2ghz


	Dominik

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Sun, Feb 26, 2006, Dominik Brodowski wrote:
> On Sun, Feb 26, 2006 at 09:39:41PM +0100, Johannes Stezenbach wrote:
> > 
> > Do you have the numbers for a Pentium(R) 4 HT? (I couldn't find
> > anything substantial with google.) Especially C2 vs. C2 + throttling?
> > Because the way I remember having read somewhere, the idle
> > (C2) power consumption of the P4 is significantly higher
> > than with the Pentium(R) M.
> 
> Unfortunately, I do not have these numbers present. You can check the
> processor specification sheets at Intel's website, though.

Went to the Intel(R) website, searched for half an hour, found many
docs but none that gives useful information about this, gave up. :-(

> > > So: P4-clockmod style throttling only makes sense if either
> > > 
> > > a) the idle handler does not enter the Stop-Grant state (C2) efficiently, or
> > 
> > Maybe my previous mails were not clear enough: The goal is to
> > reduce idle power consumption (and by that fan noise). The PC
> > is running but is idle, e.g just listening for possible incoming
> > jabber messages or whatever.
> 
> Most probably, the idle handler can't make use of the Stop-Grant state (C2)
> here, so this is case a) noted above.

Hm.

Thanks,
Johannes

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Saturday 25 February 2006 13:53, Adrian Bunk wrote:
On Sat, Feb 25, 2006 at 05:27:01AM +0100, Andi Kleen wrote:
> > On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> > > On Thu, Feb 23, 2006, Dave Jones wrote:
> > > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> > > >  > And if the option is mostly useless, what is it good for?
> > > >
> > > > It's sometimes useful in cases where the target CPU doesn't have any
> > > > better option (Speedstep/Powernow).  The big misconception is that it
> > > > somehow saves power & increases battery life. Not so.
> > > > All it does is 'not do work so often'.  The upside of this is
> > > > that in some sit> uations, we generate less heat this way.
> > >
> > > Doesn't less heat imply less power consumption?
> >
> > Not in this case no.
> >...
>
> Sorry for the dumb question, but how could this work physically?
>
> If a computer produces less heat with the same power consumption, what
> happens with the other energy?

It's consumed over a longer time. In throttling mode the CPU skips
doing work on clock ticks. This temporarily lowers the local heat
that comes from switching transistors, but if the system has some 
computation to do it will take longer to do it until the machine can go to 
idle again and do real power saving.

This means on a global scale you're not saving anything, in fact
you're wasting more power.

There are sometimes secondary effects like the air condition
of your server room may consume less power if the peak
heat is lower, but they likely only apply in very specialized 
circumstances.

It's basically only a last measure that the CPU tries to cool itself
down a bit before forcibly shutting down. It's also not really
designed to be used in normal operation, so you end up
with problems like TSC timing being wrong or extremly
long user visible latencies to switch back to normal operation.

-Andi

Re: Status of X86_P4_CLOCKMOD?

[Johannes Stezenbach]

On Sat, Feb 25, 2006, Andi Kleen wrote:
> On Saturday 25 February 2006 02:57, Johannes Stezenbach wrote:
> > P4 clockmod certainly sucks compared to Speedstep,
> > but IMHO it is still potentially useful for the average
> > desktop PC user (at least those many who let their PCs
> > run 24/7, but 90% idle and unused).
> 
> I don't think so no. The latencies make it unusable.

I tried to explain that I think one can use it in a way
so the latencies are not a big issue. One must
just accept that it needs different policy than
Speedstep etc.


Johannes

Re: Status of X86_P4_CLOCKMOD?

[Matt Mackall]

On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
> On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> 
>  > > > >  config X86_P4_CLOCKMOD
>  > > > > 	depends on EMBEDDED
>  > > > 
>  > > > This one is an x86_64 only issue, and yes, it's wrong.
>  > > 
>  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
>  > > almost any energy savings it was "hidden" under embedded.
>  > 
>  > But the EMBEDDED dependency is only on x86_64:
>  > 
>  > arch/i386/kernel/cpu/cpufreq/Kconfig:
>  > config X86_P4_CLOCKMOD
>  >         tristate "Intel Pentium 4 clock modulation"
>  >         select CPU_FREQ_TABLE
>  >         help
>  > 
>  > arch/x86_64/kernel/cpufreq/Kconfig:
>  > config X86_P4_CLOCKMOD
>  >         tristate "Intel Pentium 4 clock modulation"
>  >         depends on EMBEDDED
>  >         help
>  > 
>  > And if the option is mostly useless, what is it good for?
> 
> It's sometimes useful in cases where the target CPU doesn't have any better
> option (Speedstep/Powernow).  The big misconception is that it
> somehow saves power & increases battery life. Not so.
> All it does is 'not do work so often'.  The upside of this is
> that in some situations, we generate less heat this way.

This is perplexing. Less heat equals less power usage according to the
laws of thermodynamics.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Status of X86_P4_CLOCKMOD?

[Dave Jones]

On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
 > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
 > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
 > > 
 > >  > > > >  config X86_P4_CLOCKMOD
 > >  > > > > 	depends on EMBEDDED
 > >  > > > 
 > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
 > >  > > 
 > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
 > >  > > almost any energy savings it was "hidden" under embedded.
 > >  > 
 > >  > But the EMBEDDED dependency is only on x86_64:
 > >  > 
 > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
 > >  > config X86_P4_CLOCKMOD
 > >  >         tristate "Intel Pentium 4 clock modulation"
 > >  >         select CPU_FREQ_TABLE
 > >  >         help
 > >  > 
 > >  > arch/x86_64/kernel/cpufreq/Kconfig:
 > >  > config X86_P4_CLOCKMOD
 > >  >         tristate "Intel Pentium 4 clock modulation"
 > >  >         depends on EMBEDDED
 > >  >         help
 > >  > 
 > >  > And if the option is mostly useless, what is it good for?
 > > 
 > > It's sometimes useful in cases where the target CPU doesn't have any better
 > > option (Speedstep/Powernow).  The big misconception is that it
 > > somehow saves power & increases battery life. Not so.
 > > All it does is 'not do work so often'.  The upside of this is
 > > that in some situations, we generate less heat this way.
 > 
 > This is perplexing. Less heat equals less power usage according to the
 > laws of thermodynamics.

you end up taking longer to do the same amount of work, so you
end up using the same overall power.

		Dave

Re: Status of X86_P4_CLOCKMOD?

[Dmitry Torokhov]

On 2/28/06, Dave Jones <davej@redhat.com> wrote:
> On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
>  >
>  > This is perplexing. Less heat equals less power usage according to the
>  > laws of thermodynamics.
>
> you end up taking longer to do the same amount of work, so you
> end up using the same overall power.
>

I'd say that energy usage is the same _per unit of work_. But if you
compare a box that is sitting idle 90% of the time at 0% throttling
vs. a box that is sitting idle 80% of the time with 50% throttling and
neither of these boxes support C2 you'll find that the second box uses
less energy overall.

--
Dmitry

Re: Status of X86_P4_CLOCKMOD?

[Matt Mackall]

On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote:
> On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
>  > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
>  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
>  > > 
>  > >  > > > >  config X86_P4_CLOCKMOD
>  > >  > > > > 	depends on EMBEDDED
>  > >  > > > 
>  > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
>  > >  > > 
>  > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
>  > >  > > almost any energy savings it was "hidden" under embedded.
>  > >  > 
>  > >  > But the EMBEDDED dependency is only on x86_64:
>  > >  > 
>  > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
>  > >  > config X86_P4_CLOCKMOD
>  > >  >         tristate "Intel Pentium 4 clock modulation"
>  > >  >         select CPU_FREQ_TABLE
>  > >  >         help
>  > >  > 
>  > >  > arch/x86_64/kernel/cpufreq/Kconfig:
>  > >  > config X86_P4_CLOCKMOD
>  > >  >         tristate "Intel Pentium 4 clock modulation"
>  > >  >         depends on EMBEDDED
>  > >  >         help
>  > >  > 
>  > >  > And if the option is mostly useless, what is it good for?
>  > > 
>  > > It's sometimes useful in cases where the target CPU doesn't have any better
>  > > option (Speedstep/Powernow).  The big misconception is that it
>  > > somehow saves power & increases battery life. Not so.
>  > > All it does is 'not do work so often'.  The upside of this is
>  > > that in some situations, we generate less heat this way.
>  > 
>  > This is perplexing. Less heat equals less power usage according to the
>  > laws of thermodynamics.
> 
> you end up taking longer to do the same amount of work, so you
> end up using the same overall power.

Doesn't make sense.

Power is energy consumption per unit time. Heat is energy dissipated
per unit time (both are measured in watts). So if you're saying "we
use the same amount of power", then conservation of energy implies "we
generate the same amount of heat." If you're instead saying "we use
the same amount of energy over a longer span of time", that means "we
draw less power from the battery" which means "battery lasts longer".

In short, power usage and heat production are _the same thing_.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

On Tue, Feb 28, 2006 at 02:47:20PM -0600, Matt Mackall wrote:
> On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote:
> > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
> >  > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
> >  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> >  > > 
> >  > >  > > > >  config X86_P4_CLOCKMOD
> >  > >  > > > > 	depends on EMBEDDED
> >  > >  > > > 
> >  > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
> >  > >  > > 
> >  > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
> >  > >  > > almost any energy savings it was "hidden" under embedded.
> >  > >  > 
> >  > >  > But the EMBEDDED dependency is only on x86_64:
> >  > >  > 
> >  > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
> >  > >  > config X86_P4_CLOCKMOD
> >  > >  >         tristate "Intel Pentium 4 clock modulation"
> >  > >  >         select CPU_FREQ_TABLE
> >  > >  >         help
> >  > >  > 
> >  > >  > arch/x86_64/kernel/cpufreq/Kconfig:
> >  > >  > config X86_P4_CLOCKMOD
> >  > >  >         tristate "Intel Pentium 4 clock modulation"
> >  > >  >         depends on EMBEDDED
> >  > >  >         help
> >  > >  > 
> >  > >  > And if the option is mostly useless, what is it good for?
> >  > > 
> >  > > It's sometimes useful in cases where the target CPU doesn't have any better
> >  > > option (Speedstep/Powernow).  The big misconception is that it
> >  > > somehow saves power & increases battery life. Not so.
> >  > > All it does is 'not do work so often'.  The upside of this is
> >  > > that in some situations, we generate less heat this way.
> >  > 
> >  > This is perplexing. Less heat equals less power usage according to the
> >  > laws of thermodynamics.
> > 
> > you end up taking longer to do the same amount of work, so you
> > end up using the same overall power.
> 
> Doesn't make sense.
> 
> Power is energy consumption per unit time. Heat is energy dissipated
> per unit time (both are measured in watts). So if you're saying "we
> use the same amount of power", then conservation of energy implies "we
> generate the same amount of heat." If you're instead saying "we use
> the same amount of energy over a longer span of time", that means "we
> draw less power from the battery" which means "battery lasts longer".

So even if the battery lasts longer, you don't have anything of it, 'cause
the CPU can even compute _less_ in this longer time-span. Remember that
idling doesn't count...

> In short, power usage and heat production are _the same thing_.

Yes and no. The heat production is more levelled if you use throttling, so
the temperature achieved is lesser, which might cause fans not having to
start or air conditioning having less work to do.

	Dominik

Re: Status of X86_P4_CLOCKMOD?

[Matt Mackall]

On Tue, Feb 28, 2006 at 09:57:58PM +0100, Dominik Brodowski wrote:
> On Tue, Feb 28, 2006 at 02:47:20PM -0600, Matt Mackall wrote:
> > On Tue, Feb 28, 2006 at 03:09:16PM -0500, Dave Jones wrote:
> > > On Tue, Feb 28, 2006 at 01:46:29PM -0600, Matt Mackall wrote:
> > >  > On Thu, Feb 23, 2006 at 03:41:10PM -0500, Dave Jones wrote:
> > >  > > On Thu, Feb 23, 2006 at 08:59:37PM +0100, Adrian Bunk wrote:
> > >  > > 
> > >  > >  > > > >  config X86_P4_CLOCKMOD
> > >  > >  > > > > 	depends on EMBEDDED
> > >  > >  > > > 
> > >  > >  > > > This one is an x86_64 only issue, and yes, it's wrong.
> > >  > >  > > 
> > >  > >  > > That's for P4, not X86_64... And since P4 clock modulation does not provide
> > >  > >  > > almost any energy savings it was "hidden" under embedded.
> > >  > >  > 
> > >  > >  > But the EMBEDDED dependency is only on x86_64:
> > >  > >  > 
> > >  > >  > arch/i386/kernel/cpu/cpufreq/Kconfig:
> > >  > >  > config X86_P4_CLOCKMOD
> > >  > >  >         tristate "Intel Pentium 4 clock modulation"
> > >  > >  >         select CPU_FREQ_TABLE
> > >  > >  >         help
> > >  > >  > 
> > >  > >  > arch/x86_64/kernel/cpufreq/Kconfig:
> > >  > >  > config X86_P4_CLOCKMOD
> > >  > >  >         tristate "Intel Pentium 4 clock modulation"
> > >  > >  >         depends on EMBEDDED
> > >  > >  >         help
> > >  > >  > 
> > >  > >  > And if the option is mostly useless, what is it good for?
> > >  > > 
> > >  > > It's sometimes useful in cases where the target CPU doesn't have any better
> > >  > > option (Speedstep/Powernow).  The big misconception is that it
> > >  > > somehow saves power & increases battery life. Not so.
> > >  > > All it does is 'not do work so often'.  The upside of this is
> > >  > > that in some situations, we generate less heat this way.
> > >  > 
> > >  > This is perplexing. Less heat equals less power usage according to the
> > >  > laws of thermodynamics.
> > > 
> > > you end up taking longer to do the same amount of work, so you
> > > end up using the same overall power.
> > 
> > Doesn't make sense.
> > 
> > Power is energy consumption per unit time. Heat is energy dissipated
> > per unit time (both are measured in watts). So if you're saying "we
> > use the same amount of power", then conservation of energy implies "we
> > generate the same amount of heat." If you're instead saying "we use
> > the same amount of energy over a longer span of time", that means "we
> > draw less power from the battery" which means "battery lasts longer".
> 
> So even if the battery lasts longer, you don't have anything of it, 'cause
> the CPU can even compute _less_ in this longer time-span. Remember that
> idling doesn't count...

Which is different from other power-saving modes how? If it means I
can read my email longer on the plane, it's a power-saving mode.
 
> > In short, power usage and heat production are _the same thing_.
> 
> Yes and no. The heat production is more levelled if you use throttling, so
> the temperature achieved is lesser, which might cause fans not having to
> start or air conditioning having less work to do.

The time scale for heat propagation is enough slower than throttling
that I'd expect this difference to amount to approximately nil. It
takes many seconds for heat to propagate from a core to a thermal
sensor inside a laptop, and the intervening material (silicon,
ceramic, plastic, aluminum, air) acts as a low-pass filter so usage
spikes on sub-second scales are simply not visible. In other words,
the temperature will be the same for the same energy consumption
averaged over the time it takes for the heat to propagate.

And the time for a usage spike to be visible to a server room air
conditioner is probably closer to a ten minute time frame.

-- 
Mathematics is the supreme nostalgia of our time.

Re: Status of X86_P4_CLOCKMOD?

[Dominik Brodowski]

On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote:
> > So even if the battery lasts longer, you don't have anything of it, 'cause
> > the CPU can even compute _less_ in this longer time-span. Remember that
> > idling doesn't count...
> 
> Which is different from other power-saving modes how? If it means I
> can read my email longer on the plane, it's a power-saving mode.

But you can't... [*]

> > > In short, power usage and heat production are _the same thing_.
> > 
> > Yes and no. The heat production is more levelled if you use throttling, so
> > the temperature achieved is lesser, which might cause fans not having to
> > start or air conditioning having less work to do.
> 
> The time scale for heat propagation is enough slower than throttling
> that I'd expect this difference to amount to approximately nil.

For short-term load spikes, yes. If your server has a task which takes up
one hour at full time, and the temp reaches 45° C then, but you have nothing
else for it to do overnight, then it does might sense to throttle it to
50%, which will mean two hours, but only 40° C.

	Dominik


[*] unless the idling algorithm is broken and does not enter C2-type idle
states.

Re: Status of X86_P4_CLOCKMOD?

[Dmitry Torokhov]

On 2/28/06, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote:
> > > So even if the battery lasts longer, you don't have anything of it, 'cause
> > > the CPU can even compute _less_ in this longer time-span. Remember that
> > > idling doesn't count...
> >
> > Which is different from other power-saving modes how? If it means I
> > can read my email longer on the plane, it's a power-saving mode.
>
> But you can't... [*]
...
> [*] unless the idling algorithm is broken and does not enter C2-type idle
> states.

Or box does not support anything but C1.

--
Dmitry

Re: Status of X86_P4_CLOCKMOD?

[Andi Kleen]

On Tuesday 28 February 2006 22:39, Dmitry Torokhov wrote:
> On 2/28/06, Dominik Brodowski <linux@dominikbrodowski.net> wrote:
> > On Tue, Feb 28, 2006 at 03:26:32PM -0600, Matt Mackall wrote:
> > > > So even if the battery lasts longer, you don't have anything of it, 'cause
> > > > the CPU can even compute _less_ in this longer time-span. Remember that
> > > > idling doesn't count...
> > >
> > > Which is different from other power-saving modes how? If it means I
> > > can read my email longer on the plane, it's a power-saving mode.
> >
> > But you can't... [*]
> ...
> > [*] unless the idling algorithm is broken and does not enter C2-type idle
> > states.
> 
> Or box does not support anything but C1.

There are quite advanced forms of C1 around.
And I would expect even old style dumb C1 to save more than throttling.

-Andi

Re: [2.6 patch] make INPUT a bool

[Herbert Poetzl]

On Wed, Feb 22, 2006 at 04:10:01AM +0100, Adrian Bunk wrote:
> On Wed, Feb 22, 2006 at 03:44:38AM +0100, Herbert Poetzl wrote:
> > On Wed, Feb 22, 2006 at 03:31:21AM +0100, Adrian Bunk wrote:
> > > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote:
> > > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> > > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> > > > > 
> > > > > > Hi Adrian,
> > > > > 
> > > > > Hi Samuel,
> > > > > 
> > > > > > > And I've already given numbers why CONFIG_EMBEDDED=y and
> > > > > > > CONFIG_MODULES=y at the same time is insane.
> > > > > > 
> > > > > > >From your numbers this sounds true ... but actually you might want the
> > > > > > modules to delay the init of the various hardware bits...
> > > > > > 
> > > > > > Sometime boot-time is king and you just try and get back as much of
> > > > > > the size costs as it takes...
> > > > > 
> > > > > this is irrelevant since CONFIG_INPUT alone does not init any hardware.
> > > > > 
> > > > > > I think for EMBEDDED and MODULES is actually a very common case ... if
> > > > > > somewhat odd.
> > > > > 
> > > > > You are misunderstanding EMBEDDED.
> > > > 
> > > > well, I suggested the following (or a similar)
> > > > change some time ago (unfortunately I could not
> > > > find it in the lkml archives, so it might have
> > > > been lost)
> > > > 
> > > > http://vserver.13thfloor.at/Stuff/embedded_to_expert.txt
> > > 
> > > That's not a good solution since EMBEDDED is really only about 
> > > additional space savings - even if you are an "expert", there's no 
> > > reason to enable EMBEDDED when building a kernel for systems 
> > > with > 50 MB RAM.
> > 
> > well, not sure everybody kows that ...
> > 
> >  config X86_P4_CLOCKMOD
> > 	depends on EMBEDDED
> 
> This one is an x86_64 only issue, and yes, it's wrong.
> 
> >  config VT_CONSOLE
> > 	bool "Support for console on virtual terminal" if EMBEDDED
> 
> Looks OK.
> 
> >  config VGA_CONSOLE
> > 	bool "VGA text console" if EMBEDDED 
> 
> Looks OK.
> 
> >  config DNOTIFY
> > 	bool "Dnotify support" if EMBEDDED
> 
> Looks OK.
> 
> >  config DEBUG_BUGVERBOSE
> > 	bool "Verbose BUG() reporting (adds 70K)" if DEBUG_KERNEL && EMBEDDED
> 
> Looks OK.
> 
> > but, the patch was just considered a starting point
> > so that folks would know _what_ EMBEDDED is currently
> > used for ...
> 
> Except for the X86_P4_CLOCKMOD case, all of your examples are correct 
> usages of EMBEDDED.

ahem, well, then I'm definitely doing something
wrong when I disable the VGA console on my 2GB
servers, as "there's no reason to enable EMBEDDED
when building a kernel for systems with > 50 MB RAM"

sorry, I kind of disagree here, this might be useful
for embedded systems, but it is definitely useful
for other systems as well ... at least I do not like
the 'assumption' that every system with >50MB has
to have a VGA console ...

I agree that the 0815 distro will not need this and
it can be hidden behind some option ...

best,
Herbert

> > > The better solution is IMHO an additional option:
> > >   http://lkml.org/lkml/2006/2/7/93
> > >   http://lkml.org/lkml/2006/2/7/139
> > 
> > whatever, just get rid of the CONFIG_EMBEDDED everybody
> > get's wrong and nobody really understands ...
> 
> No, the EMBEDDED semantics shouldn't be changed and most people get it 
> right.
> 
> Naming it EXPERT as you suggested would make it even worse. We could name it 
> SHOW_OPTIONS_FOR_ADDITIONAL_SPACE_SAVINGS_IF_YOU_REALLY_KNOW_WHAT_YOU_ARE_DOING, 
> but unless someone comes up with a name that is both short and 
> significantely better than EMBEDDED I don't see a reason for changing it.
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Wed, Feb 22, 2006 at 01:01:21PM +0100, Herbert Poetzl wrote:
> On Wed, Feb 22, 2006 at 04:10:01AM +0100, Adrian Bunk wrote:
>...
> > Except for the X86_P4_CLOCKMOD case, all of your examples are correct 
> > usages of EMBEDDED.
> 
> ahem, well, then I'm definitely doing something
> wrong when I disable the VGA console on my 2GB
> servers, as "there's no reason to enable EMBEDDED
> when building a kernel for systems with > 50 MB RAM"
> 
> sorry, I kind of disagree here, this might be useful
> for embedded systems, but it is definitely useful
> for other systems as well ... at least I do not like
> the 'assumption' that every system with >50MB has
> to have a VGA console ...
> 
> I agree that the 0815 distro will not need this and
> it can be hidden behind some option ...

It's not assumed that every system with > 50 MB has a VGA console.

These are options where accidentially disabling only causes problems for 
the majority of users.

You can enable EMBEDDED on your 2 GB servers if you really want to save 
a few bytes in the kernel, but OTOH I doubt there is much practival 
value in reducing the kernel for a system with 2 GB RAM by a few kB.

> best,
> Herbert
>...

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Herbert Poetzl]

On Wed, Feb 22, 2006 at 01:15:42PM +0100, Adrian Bunk wrote:
> On Wed, Feb 22, 2006 at 01:01:21PM +0100, Herbert Poetzl wrote:
> > On Wed, Feb 22, 2006 at 04:10:01AM +0100, Adrian Bunk wrote:
> >...
> > > Except for the X86_P4_CLOCKMOD case, all of your examples are correct 
> > > usages of EMBEDDED.
> > 
> > ahem, well, then I'm definitely doing something
> > wrong when I disable the VGA console on my 2GB
> > servers, as "there's no reason to enable EMBEDDED
> > when building a kernel for systems with > 50 MB RAM"
> > 
> > sorry, I kind of disagree here, this might be useful
> > for embedded systems, but it is definitely useful
> > for other systems as well ... at least I do not like
> > the 'assumption' that every system with >50MB has
> > to have a VGA console ...
> > 
> > I agree that the 0815 distro will not need this and
> > it can be hidden behind some option ...
> 
> It's not assumed that every system with > 50 MB has a VGA console.
>
> These are options where accidentially disabling only causes problems
> for the majority of users.
>
> You can enable EMBEDDED on your 2 GB servers if you really want
> to save a few bytes in the kernel, but OTOH I doubt there is much
> practival value in reducing the kernel for a system with 2 GB RAM by a
> few kB.

it is not the size I care about, it is the missing/disabled
vga hardware (and serial console) that I care about, but
what the hell, you consider it EMBEDDED and I don't. period.

nevertheless folks put all kind of stuff under EMBEDDED
because they _think_ it actually means _SPECIALIST_ or
_EXPERT_ and just is bad namimg ...

that's something which IMHO should be clarified, and if it
is just by adding another Kconfig option which does that

> > best,
> > Herbert
> >...
> 
> cu
> Adrian
> 
> -- 
> 
>        "Is there not promise of rain?" Ling Tan asked suddenly out
>         of the darkness. There had been need of rain for many days.
>        "Only a promise," Lao Er said.
>                                        Pearl S. Buck - Dragon Seed
> 
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: [2.6 patch] make INPUT a bool

[Geert Uytterhoeven]

On Wed, 22 Feb 2006, Adrian Bunk wrote:
> On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote:
> > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> That's not a good solution since EMBEDDED is really only about 
> additional space savings - even if you are an "expert", there's no 
> reason to enable EMBEDDED when building a kernel for systems 
> with > 50 MB RAM.

and

On Fri, 17 Feb 2006, Adrian Bunk wrote:
> And I've already given numbers why CONFIG_EMBEDDED=y and
> CONFIG_MODULES=y at the same time is insane.

But if my m68k box has less than 47.68 MiB RAM, I may want CONFIG_EMBEDDED=y,
and I like to have CONFIG_MODULES=y...

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Sat, Feb 25, 2006 at 12:58:01PM +0100, Geert Uytterhoeven wrote:
> On Wed, 22 Feb 2006, Adrian Bunk wrote:
> > On Wed, Feb 22, 2006 at 02:34:11AM +0100, Herbert Poetzl wrote:
> > > On Mon, Feb 20, 2006 at 02:28:32PM +0100, Adrian Bunk wrote:
> > > > On Mon, Feb 20, 2006 at 12:33:55PM +0900, Samuel Masham wrote:
> > That's not a good solution since EMBEDDED is really only about 
> > additional space savings - even if you are an "expert", there's no 
> > reason to enable EMBEDDED when building a kernel for systems 
> > with > 50 MB RAM.
> 
> and
> 
> On Fri, 17 Feb 2006, Adrian Bunk wrote:
> > And I've already given numbers why CONFIG_EMBEDDED=y and
> > CONFIG_MODULES=y at the same time is insane.
> 
> But if my m68k box has less than 47.68 MiB RAM, I may want CONFIG_EMBEDDED=y,
> and I like to have CONFIG_MODULES=y...

My 50 MB number was much too high (I didn't want to think where exactly 
to set the borderline).

My point is that if you are in an environment that is that space limited 
that you want to see options that allow e.g. not building futexes, 
module support with an impact of approx. 10% on code size would be one 
of the first things you should disable.

> Gr{oetje,eeting}s,
> 						Geert

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Jan Engelhardt]

>
>My 50 MB number was much too high (I didn't want to think where exactly 
>to set the borderline).
>
>My point is that if you are in an environment that is that space limited 
>that you want to see options that allow e.g. not building futexes, 
>module support with an impact of approx. 10% on code size would be one 
>of the first things you should disable.
>

You said that INPUT was not a driver, right. But without it, a keyboard 
won't work, will it?



Jan Engelhardt
-- 

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Sat, Feb 25, 2006 at 03:22:04PM +0100, Jan Engelhardt wrote:
> >
> >My 50 MB number was much too high (I didn't want to think where exactly 
> >to set the borderline).
> >
> >My point is that if you are in an environment that is that space limited 
> >that you want to see options that allow e.g. not building futexes, 
> >module support with an impact of approx. 10% on code size would be one 
> >of the first things you should disable.
> >
> 
> You said that INPUT was not a driver, right. But without it, a keyboard 
> won't work, will it?

Yes, you do need INPUT for a keyboard.

No, INPUT alone does not support any hardware - that's the job of the 
drivers depending on INPUT.

No, I don't understand what your question wants to achieve.

> Jan Engelhardt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Jan Engelhardt]

>> 
>> You said that INPUT was not a driver, right. But without it, a keyboard 
>> won't work, will it?
>
>Yes, you do need INPUT for a keyboard.
>
>No, INPUT alone does not support any hardware - that's the job of the 
>drivers depending on INPUT.
>
>No, I don't understand what your question wants to achieve.
>

Let's look at another subsystem:

"Yes, you do need SND for a soundcard."

"No, SND alone does not support any hardware - that's the job of the drivers
depending on SND."

Should SND also be made a bool like INPUT?


Jan Engelhardt
-- 

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Sat, Feb 25, 2006 at 04:29:16PM +0100, Jan Engelhardt wrote:
> >> 
> >> You said that INPUT was not a driver, right. But without it, a keyboard 
> >> won't work, will it?
> >
> >Yes, you do need INPUT for a keyboard.
> >
> >No, INPUT alone does not support any hardware - that's the job of the 
> >drivers depending on INPUT.
> >
> >No, I don't understand what your question wants to achieve.
> >
> 
> Let's look at another subsystem:
> 
> "Yes, you do need SND for a soundcard."
> 
> "No, SND alone does not support any hardware - that's the job of the drivers
> depending on SND."
> 
> Should SND also be made a bool like INPUT?

No, SND=m is also possible in the EMBEDDED=n case.

> Jan Engelhardt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Jan Engelhardt]

>> >> You said that INPUT was not a driver, right. But without it, a keyboard 
>> >> won't work, will it?
>> >
>> >Yes, you do need INPUT for a keyboard.
>> >No, INPUT alone does not support any hardware - that's the job of the 
>> >drivers depending on INPUT.
>> >No, I don't understand what your question wants to achieve.
>> 
>> Let's look at another subsystem:
>> "Yes, you do need SND for a soundcard."
>> "No, SND alone does not support any hardware - that's the job of the drivers
>> depending on SND."
>> Should SND also be made a bool like INPUT?
>
>No, SND=m is also possible in the EMBEDDED=n case.
>
This example was to show that INPUT should not be y-only. Except if you plan to
make SND y-only too.


Jan Engelhardt
-- 

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Sat, Feb 25, 2006 at 11:01:03PM +0100, Jan Engelhardt wrote:
> >> >> You said that INPUT was not a driver, right. But without it, a keyboard 
> >> >> won't work, will it?
> >> >
> >> >Yes, you do need INPUT for a keyboard.
> >> >No, INPUT alone does not support any hardware - that's the job of the 
> >> >drivers depending on INPUT.
> >> >No, I don't understand what your question wants to achieve.
> >> 
> >> Let's look at another subsystem:
> >> "Yes, you do need SND for a soundcard."
> >> "No, SND alone does not support any hardware - that's the job of the drivers
> >> depending on SND."
> >> Should SND also be made a bool like INPUT?
> >
> >No, SND=m is also possible in the EMBEDDED=n case.
> >
> This example was to show that INPUT should not be y-only. Except if you plan to
> make SND y-only too.


Please try to understand the following:
- INPUT=m is already only available if EMBEDDED=y
- as I did already explain, EMBEDDED=y and MODULES=y at the same 
  time doesn't make much  sense

As I already said, SND=m is completely different since it is also 
available in the (common) EMBEDDED=n case.


> Jan Engelhardt

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Dmitry Torokhov]

On Saturday 25 February 2006 17:07, Adrian Bunk wrote:
> On Sat, Feb 25, 2006 at 11:01:03PM +0100, Jan Engelhardt wrote:
> > >> >> You said that INPUT was not a driver, right. But without it, a keyboard 
> > >> >> won't work, will it?
> > >> >
> > >> >Yes, you do need INPUT for a keyboard.
> > >> >No, INPUT alone does not support any hardware - that's the job of the 
> > >> >drivers depending on INPUT.
> > >> >No, I don't understand what your question wants to achieve.
> > >> 
> > >> Let's look at another subsystem:
> > >> "Yes, you do need SND for a soundcard."
> > >> "No, SND alone does not support any hardware - that's the job of the drivers
> > >> depending on SND."
> > >> Should SND also be made a bool like INPUT?
> > >
> > >No, SND=m is also possible in the EMBEDDED=n case.
> > >
> > This example was to show that INPUT should not be y-only. Except if you plan to
> > make SND y-only too.
> 
> 
> Please try to understand the following:
> - INPUT=m is already only available if EMBEDDED=y

Adrian,

There are requests to move it out of EMBEDDED because sometimes you
just  don't need input layer at all. Dave Jones mentioned that he
feels silly enabling EMBEDDED on iSeries... I am thinking about
changing it to "EMBEDDED || !X86_PC" to safe-guard the most common
platform from accidenially disabling it.

I am still not convinced whether INPUT=m makes sence, especially if
we make ACPI use input layer... Jan's example about input device with
hot-pluggable keyboard is a bit of a stretch. 

-- 
Dmitry

Re: [2.6 patch] make INPUT a bool

[Adrian Bunk]

On Sat, Feb 25, 2006 at 05:23:52PM -0500, Dmitry Torokhov wrote:
> 
> Adrian,
> 
> There are requests to move it out of EMBEDDED because sometimes you
> just  don't need input layer at all. Dave Jones mentioned that he
> feels silly enabling EMBEDDED on iSeries... I am thinking about
> changing it to "EMBEDDED || !X86_PC" to safe-guard the most common
> platform from accidenially disabling it.

Sounds reasonable.

> I am still not convinced whether INPUT=m makes sence, especially if
> we make ACPI use input layer... Jan's example about input device with
> hot-pluggable keyboard is a bit of a stretch. 

Agreed.

> Dmitry

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: [2.6 patch] make INPUT a bool

[Vojtech Pavlik]

On Sat, Feb 25, 2006 at 05:23:52PM -0500, Dmitry Torokhov wrote:
 
> Adrian,
> 
> There are requests to move it out of EMBEDDED because sometimes you
> just  don't need input layer at all. Dave Jones mentioned that he
> feels silly enabling EMBEDDED on iSeries... I am thinking about
> changing it to "EMBEDDED || !X86_PC" to safe-guard the most common
> platform from accidenially disabling it.
> 
> I am still not convinced whether INPUT=m makes sence, especially if
> we make ACPI use input layer... Jan's example about input device with
> hot-pluggable keyboard is a bit of a stretch. 
 
The possibility to keep INPUT=m makes a big sense in that it keeps the
interfaces to the rest of the kernel clean. No direct linking, no
callbacks into inner functions from elsewhere, etc. Nicely isolated.

Even with ACPI, the part that will use input will usually be modular,
too.

The only big user of INPUT, which can't be modular at the time is
CONFIG_VT. And this, I believe, is a bug.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [2.6 patch] make INPUT a bool

[Vojtech Pavlik]

On Sat, Feb 25, 2006 at 11:07:38PM +0100, Adrian Bunk wrote:
> On Sat, Feb 25, 2006 at 11:01:03PM +0100, Jan Engelhardt wrote:
> > >> >> You said that INPUT was not a driver, right. But without it, a keyboard 
> > >> >> won't work, will it?
> > >> >
> > >> >Yes, you do need INPUT for a keyboard.
> > >> >No, INPUT alone does not support any hardware - that's the job of the 
> > >> >drivers depending on INPUT.
> > >> >No, I don't understand what your question wants to achieve.
> > >> 
> > >> Let's look at another subsystem:
> > >> "Yes, you do need SND for a soundcard."
> > >> "No, SND alone does not support any hardware - that's the job of the drivers
> > >> depending on SND."
> > >> Should SND also be made a bool like INPUT?
> > >
> > >No, SND=m is also possible in the EMBEDDED=n case.
> > >
> > This example was to show that INPUT should not be y-only. Except if you plan to
> > make SND y-only too.
> 
> 
> Please try to understand the following:
> - INPUT=m is already only available if EMBEDDED=y

That is because too many people were making the mistake of saying 'N' to
INPUT. EMBEDDED here was really chosen while meaning EXPERT. This has
nothing to do with the kernel image size - the size of input.c is pretty
minimal anyway.

> - as I did already explain, EMBEDDED=y and MODULES=y at the same 
>   time doesn't make much  sense

It doesn't. But in the same way making INPUT depend on EMBEDDED doesn't
make sense if you intend EMBEDDED to truly mean what it says.

> As I already said, SND=m is completely different since it is also 
> available in the (common) EMBEDDED=n case.
 
It's not. Input, like sound, scsi, usb, firewire .... is just another
subsystem in the kernel. The kernel can live without it, and it used to
work just fine when all modular, including autoloading.

-- 
Vojtech Pavlik
Director SuSE Labs

Re: [2.6 patch] make INPUT a bool

[Jesper Juhl]

On 2/25/06, Jan Engelhardt <jengelh@linux01.gwdg.de> wrote:
> >
> >My 50 MB number was much too high (I didn't want to think where exactly
> >to set the borderline).
> >
> >My point is that if you are in an environment that is that space limited
> >that you want to see options that allow e.g. not building futexes,
> >module support with an impact of approx. 10% on code size would be one
> >of the first things you should disable.
> >
>
> You said that INPUT was not a driver, right. But without it, a keyboard
> won't work, will it?
>
No, it won't, so if you want to use a keyboard you build INPUT into the kernel.

--
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [2.6 patch] make INPUT a bool

[Dmitry Torokhov]

On Tuesday 14 February 2006 10:22, Adrian Bunk wrote:
> Make INPUT a bool.
> 
> INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
> make that much sense to make it modular.
>

Adrian,

We also need to get rid of input_register_device pinning input module
and input_dev release function decrementing module's refcount.

Thanks!

-- 
Dmitry

[2.6 patch] make INPUT a bool

[Adrian Bunk]

On Wed, Feb 15, 2006 at 01:20:58AM -0500, Dmitry Torokhov wrote:
> On Tuesday 14 February 2006 10:22, Adrian Bunk wrote:
> > Make INPUT a bool.
> > 
> > INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
> > make that much sense to make it modular.
> >
> 
> Adrian,
> 
> We also need to get rid of input_register_device pinning input module
> and input_dev release function decrementing module's refcount.

Is the patch below OK?

> Thanks!
> Dmitry

cu
Adrian


<--  snip  -->


Make INPUT a bool.

INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
make that much sense to make it modular.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/input/Kconfig |    2 +-
 drivers/input/input.c |   21 ---------------------
 2 files changed, 1 insertion(+), 22 deletions(-)

--- linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig.old	2006-02-03 22:42:18.000000000 +0100
+++ linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig	2006-02-03 22:42:29.000000000 +0100
@@ -5,7 +5,7 @@
 menu "Input device support"
 
 config INPUT
-	tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED
+	bool "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED
 	default y
 	---help---
 	  Say Y here if you have any input device (mouse, keyboard, tablet,
--- linux-2.6.16-rc3-mm1-full/drivers/input/input.c.old	2006-02-16 23:59:47.000000000 +0100
+++ linux-2.6.16-rc3-mm1-full/drivers/input/input.c	2006-02-17 00:06:06.000000000 +0100
@@ -23,10 +23,6 @@
 #include <linux/device.h>
 #include <linux/mutex.h>
 
-MODULE_AUTHOR("Vojtech Pavlik <vojtech@suse.cz>");
-MODULE_DESCRIPTION("Input core");
-MODULE_LICENSE("GPL");
-
 EXPORT_SYMBOL(input_allocate_device);
 EXPORT_SYMBOL(input_register_device);
 EXPORT_SYMBOL(input_unregister_device);
@@ -470,13 +466,10 @@
 	if (!proc_bus_input_dir)
 		return -ENOMEM;
 
-	proc_bus_input_dir->owner = THIS_MODULE;
-
 	entry = create_proc_read_entry("devices", 0, proc_bus_input_dir, input_devices_read, NULL);
 	if (!entry)
 		goto fail1;
 
-	entry->owner = THIS_MODULE;
 	input_fileops = *entry->proc_fops;
 	input_fileops.poll = input_devices_poll;
 	entry->proc_fops = &input_fileops;
@@ -485,8 +478,6 @@
 	if (!entry)
 		goto fail2;
 
-	entry->owner = THIS_MODULE;
-
 	return 0;
 
  fail2:	remove_proc_entry("devices", proc_bus_input_dir);
@@ -662,7 +653,6 @@
 	struct input_dev *dev = to_input_dev(class_dev);
 
 	kfree(dev);
-	module_put(THIS_MODULE);
 }
 
 /*
@@ -830,8 +820,6 @@
 	if (error)
 		goto fail3;
 
-	__module_get(THIS_MODULE);
-
 	path = kobject_get_path(&dev->cdev.kobj, GFP_KERNEL);
 	printk(KERN_INFO "input: %s as %s\n",
 		dev->name ? dev->name : "Unspecified device", path ? path : "N/A");
@@ -953,7 +941,6 @@
 }
 
 static struct file_operations input_fops = {
-	.owner = THIS_MODULE,
 	.open = input_open_file,
 };
 
@@ -984,12 +971,4 @@
 	return err;
 }
 
-static void __exit input_exit(void)
-{
-	input_proc_exit();
-	unregister_chrdev(INPUT_MAJOR, "input");
-	class_unregister(&input_class);
-}
-
 subsys_initcall(input_init);
-module_exit(input_exit);

Re: [2.6 patch] make INPUT a bool

[Dmitry Torokhov]

On 2/16/06, Adrian Bunk <bunk@stusta.de> wrote:
> On Wed, Feb 15, 2006 at 01:20:58AM -0500, Dmitry Torokhov wrote:
> > On Tuesday 14 February 2006 10:22, Adrian Bunk wrote:
> > > Make INPUT a bool.
> > >
> > > INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't
> > > make that much sense to make it modular.
> > >
> >
> > Adrian,
> >
> > We also need to get rid of input_register_device pinning input module
> > and input_dev release function decrementing module's refcount.
>
> Is the patch below OK?
>

Looks great! Thank you, Adrian.

--
Dmitry

[PATCH] Export symbols so CONFIG_INPUT works as a module

[Martin Michlmayr]

Currently, modular input support fails to load with the following error:

qube:# modprobe input
input: Unknown symbol kobject_get_path
input: Unknown symbol add_input_randomness

In the short run, this can be solved by exporting these two symbols.
There have been discussions about fixing this in a different manner,
see http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/1068.html
Since this was in the days of 2.6.12-rc4 and modular input support is
still broken, I suggest these symbols to be exported for now.

Signed-off-by: Martin Michlmayr <tbm@cyrius.com>

---

 drivers/char/random.c |    2 ++
 lib/kobject.c         |    1 +
 2 files changed, 3 insertions(+)

--- a/drivers/char/random.c	2006-01-24 18:11:26.000000000 +0000
+++ b/drivers/char/random.c	2006-01-24 18:11:57.000000000 +0000
@@ -647,6 +647,8 @@
 			     (type << 4) ^ code ^ (code >> 4) ^ value);
 }
 
+EXPORT_SYMBOL(add_input_randomness);
+
 void add_interrupt_randomness(int irq)
 {
 	if (irq >= NR_IRQS || irq_timer_state[irq] == 0)
--- a/lib/kobject.c	2006-01-24 18:12:15.000000000 +0000
+++ b/lib/kobject.c	2006-01-24 18:12:43.000000000 +0000
@@ -527,6 +527,7 @@
 EXPORT_SYMBOL(kobject_init);
 EXPORT_SYMBOL(kobject_register);
 EXPORT_SYMBOL(kobject_unregister);
+EXPORT_SYMBOL(kobject_get_path);
 EXPORT_SYMBOL(kobject_get);
 EXPORT_SYMBOL(kobject_put);
 EXPORT_SYMBOL(kobject_add);

-- 
Martin Michlmayr
http://www.cyrius.com/

Re: [PATCH] Export symbols so CONFIG_INPUT works as a module

[Dmitry Torokhov]

On 1/24/06, Al Viro <viro@ftp.linux.org.uk> wrote:
> On Tue, Jan 24, 2006 at 01:34:32PM -0500, Dave Jones wrote:
> > On Tue, Jan 24, 2006 at 06:19:45PM +0000, Martin Michlmayr wrote:
> >  > Currently, modular input support fails to load with the following error:
> >  >
> >  > qube:# modprobe input
> >  > input: Unknown symbol kobject_get_path
> >  > input: Unknown symbol add_input_randomness
> >  >
> >  > In the short run, this can be solved by exporting these two symbols.
> >  > There have been discussions about fixing this in a different manner,
> >  > see http://www.ussg.iu.edu/hypermail/linux/kernel/0505.2/1068.html
> >  > Since this was in the days of 2.6.12-rc4 and modular input support is
> >  > still broken, I suggest these symbols to be exported for now.
> >
> > Is there actually any practical reason why you would want to
> > make the input layer modular ?
>
> More interesting question: is pis^H^H^Hsysfs interaction in there safe for
> modular code?

The core should be safe, at least I was trying to make it this way, so
if you see something wrong - shout. Locking is another question
though...

--
Dmitry

Re: [PATCH] Export symbols so CONFIG_INPUT works as a module

[Martin Michlmayr]

* Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-01-24 18:08]:
> > More interesting question: is pis^H^H^Hsysfs interaction in there safe for
> > modular code?
> 
> The core should be safe, at least I was trying to make it this way, so
> if you see something wrong - shout. Locking is another question
> though...

So do you want an updated patch using _GPL to export the symbols or to
change CONFIG_INPUT to boolean?
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: [PATCH] Export symbols so CONFIG_INPUT works as a module

[Dmitry Torokhov]

On Tuesday 24 January 2006 18:14, Martin Michlmayr wrote:
> * Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-01-24 18:08]:
> > > More interesting question: is pis^H^H^Hsysfs interaction in there safe for
> > > modular code?
> > 
> > The core should be safe, at least I was trying to make it this way, so
> > if you see something wrong - shout. Locking is another question
> > though...
> 
> So do you want an updated patch using _GPL to export the symbols or to
> change CONFIG_INPUT to boolean?

I guess having input core as a module does not make much sense, so
we should change CONFIG_INPUT to be boolean _and_ clean up the core
code removing module unloading support.

-- 
Dmitry

[2.6 patch] make INPUT a bool

[Adrian Bunk]

On Wed, Jan 25, 2006 at 12:04:06AM -0500, Dmitry Torokhov wrote:
> On Tuesday 24 January 2006 18:14, Martin Michlmayr wrote:
> > * Dmitry Torokhov <dmitry.torokhov@gmail.com> [2006-01-24 18:08]:
> > > > More interesting question: is pis^H^H^Hsysfs interaction in there safe for
> > > > modular code?
> > > 
> > > The core should be safe, at least I was trying to make it this way, so
> > > if you see something wrong - shout. Locking is another question
> > > though...
> > 
> > So do you want an updated patch using _GPL to export the symbols or to
> > change CONFIG_INPUT to boolean?
> 
> I guess having input core as a module does not make much sense, so
> we should change CONFIG_INPUT to be boolean _and_ clean up the core
> code removing module unloading support.

Is the patch below what you were thinking of?

> Dmitry

cu
Adrian


<--  snip  -->


Make INPUT a bool.

INPUT!=y is only possible if EMBEDDED=y, and in such cases it doesn't 
make that much sense to make it modular.


Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/input/Kconfig |    2 +-
 drivers/input/input.c |    8 --------
 2 files changed, 1 insertion(+), 9 deletions(-)

--- linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig.old	2006-02-03 22:42:18.000000000 +0100
+++ linux-2.6.16-rc1-mm5-full/drivers/input/Kconfig	2006-02-03 22:42:29.000000000 +0100
@@ -5,7 +5,7 @@
 menu "Input device support"
 
 config INPUT
-	tristate "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED
+	bool "Generic input layer (needed for keyboard, mouse, ...)" if EMBEDDED
 	default y
 	---help---
 	  Say Y here if you have any input device (mouse, keyboard, tablet,
--- linux-2.6.16-rc1-mm5-full/drivers/input/input.c.old	2006-02-03 22:42:41.000000000 +0100
+++ linux-2.6.16-rc1-mm5-full/drivers/input/input.c	2006-02-03 22:47:44.000000000 +0100
@@ -984,12 +984,4 @@
 	return err;
 }
 
-static void __exit input_exit(void)
-{
-	input_proc_exit();
-	unregister_chrdev(INPUT_MAJOR, "input");
-	class_unregister(&input_class);
-}
-
 subsys_initcall(input_init);
-module_exit(input_exit);