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