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 <[email protected]>
---
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/
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...
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
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?
* Dave Jones <[email protected]> [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/
On Tue, Jan 24, 2006 at 07:08:39PM +0000, Martin Michlmayr wrote:
> * Dave Jones <[email protected]> [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
On 1/24/06, Al Viro <[email protected]> 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
* Dmitry Torokhov <[email protected]> [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/
On Tuesday 24 January 2006 18:14, Martin Michlmayr wrote:
> * Dmitry Torokhov <[email protected]> [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
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 <[email protected]> [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
* Vojtech Pavlik <[email protected]> [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/
>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
--
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 <[email protected]> [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
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 <[email protected]> [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 <[email protected]>
---
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);