[PATCH] Export symbols so CONFIG_INPUT works as a module

[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

[Arjan van de Ven]

On Tue, 2006-01-24 at 18:19 +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.


better make these _GPL exports to make sure people understand these are
internal things...

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

[Dave Jones]

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 ?

		Dave

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

[Al Viro]

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?

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

[Martin Michlmayr]

* Dave Jones <davej@redhat.com> [2006-01-24 13:34]:
> Is there actually any practical reason why you would want to
> make the input layer modular ?

Not really, but if it doesn't work as a module then Kbuild shouldn't
allow you to configure it like that.
-- 
Martin Michlmayr
http://www.cyrius.com/

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

[Dave Jones]

On Tue, Jan 24, 2006 at 07:08:39PM +0000, Martin Michlmayr wrote:
 > * Dave Jones <davej@redhat.com> [2006-01-24 13:34]:
 > > Is there actually any practical reason why you would want to
 > > make the input layer modular ?
 > 
 > Not really, but if it doesn't work as a module then Kbuild shouldn't
 > allow you to configure it like that.

That's the point I'm trying to make.  If there's no good reason,
it may as well be boolean.

		Dave

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

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

[Vojtech Pavlik]

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.
 
Well, USB or SCSI cores are also modules, so I think there is some point
in having that functionality.

What were the required symbols?

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR

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

[Martin Michlmayr]

* Vojtech Pavlik <vojtech@suse.cz> [2006-01-25 08:51]:
> Well, USB or SCSI cores are also modules, so I think there is some point
> in having that functionality.
> 
> What were the required symbols?

input: Unknown symbol kobject_get_path
input: Unknown symbol add_input_randomness

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

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

[Jan Engelhardt]

>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.

Embedded devices with keyboard hotplugging?


Jan Engelhardt
-- 

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

[Adrian Bunk]

On Wed, Jan 25, 2006 at 08:51:59AM +0100, Vojtech Pavlik wrote:
> 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.
>  
> Well, USB or SCSI cores are also modules, so I think there is some point
> in having that functionality.
>...

The difference is that USB and SCSI are not that essential, and 
therefore not always enabled if CONFIG_EMBEDDED=n. It's therefore e.g. 
not uncommon that distributions offer modular USB and SCSI cores.

Are there really people building kernels for that much space limited 
environments that they set CONFIG_EMBEDDED=y, and at the same time want 
CONFIG_INPUT=m?

I'd have expected people using CONFIG_EMBEDDED=y to usually also set 
CONFIG_MODULES=n for getting a smaller kernel.

> Vojtech Pavlik

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

[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);

[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

[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

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

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

[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

[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