It says in the comments in drivers/char/random.c that:
* Exported interfaces ---- input
* ==============================
*
* The current exported interfaces for gathering environmental noise
* from the devices are:
*
* void add_input_randomness(unsigned int type, unsigned int code,
* unsigned int value);
* void add_interrupt_randomness(int irq);
*
* add_input_randomness() uses the input layer interrupt timing, as well as
* the event type information from the hardware.
*
[..snip..]
If "add_input_randomness" is an "Exported interface" why is it not an
exported symbol?
If I build drivers/input/input.ko, I get the error:
** Warning: "add_input_randomness" [drivers/input/input.ko] undefined!
?
Thanks
-Robin
On Mon, 18 Sep 2006 09:27:59 -0400 Robin Getz wrote:
> It says in the comments in drivers/char/random.c that:
>
> * Exported interfaces ---- input
> * ==============================
> *
> * The current exported interfaces for gathering environmental noise
> * from the devices are:
> *
> * void add_input_randomness(unsigned int type, unsigned int code,
> * unsigned int value);
> * void add_interrupt_randomness(int irq);
> *
> * add_input_randomness() uses the input layer interrupt timing, as well as
> * the event type information from the hardware.
> *
> [..snip..]
>
> If "add_input_randomness" is an "Exported interface" why is it not an
> exported symbol?
>
> If I build drivers/input/input.ko, I get the error:
>
> ** Warning: "add_input_randomness" [drivers/input/input.ko] undefined!
Yep, confirmed (after disabling CONFIG_VT and CONFIG_USB_HID)
(on 2.6.18).
On x86_64, I get both of these:
WARNING: "kobject_get_path" [drivers/input/input.ko] undefined!
WARNING: "add_input_randomness" [drivers/input/input.ko] undefined!
With USB_HID enabled, I also get:
LD .tmp_vmlinux1
drivers/built-in.o: In function `hidinput_disconnect':
(.text+0x10741e): undefined reference to `input_unregister_device'
drivers/built-in.o: In function `hidinput_connect':
(.text+0x107526): undefined reference to `input_allocate_device'
drivers/built-in.o: In function `hidinput_connect':
(.text+0x107547): undefined reference to `input_free_device'
drivers/built-in.o: In function `hidinput_connect':
(.text+0x1091a2): undefined reference to `input_register_device'
drivers/built-in.o: In function `hidinput_connect':
(.text+0x1091f2): undefined reference to `input_register_device'
drivers/built-in.o: In function `hidinput_hid_event':
(.text+0x10942f): undefined reference to `input_event'
drivers/built-in.o: In function `hidinput_hid_event':
(.text+0x1094bd): undefined reference to `input_event'
drivers/built-in.o: In function `hidinput_hid_event':
(.text+0x109507): undefined reference to `input_event'
drivers/built-in.o: In function `hidinput_hid_event':
(.text+0x109577): undefined reference to `input_event'
drivers/built-in.o: In function `hidinput_hid_event':
(.text+0x10959b): undefined reference to `input_event'
drivers/built-in.o:(.text+0x1095dc): more undefined references to `input_event' follow
so using INPUT=m has a few problems.
ISTM that we should at least fix the first 2 (by EXPORTing them).
or we don't allow INPUT=m.
You want to send a patch?
---
~Randy
Randy Dunlap said:
>ISTM that we should at least fix the first 2 (by EXPORTing them).
>or we don't allow INPUT=m.
>
>You want to send a patch?
No problem - which patch do you want? (exporting? or set INPUT to bool?)
I'll send the export later tonight if no objections.
-Robin
On Wed, 20 Sep 2006 13:04:43 -0400 Robin Getz wrote:
> Randy Dunlap said:
> >ISTM that we should at least fix the first 2 (by EXPORTing them).
> >or we don't allow INPUT=m.
> >
> >You want to send a patch?
>
> No problem - which patch do you want? (exporting? or set INPUT to bool?)
>
> I'll send the export later tonight if no objections.
I meant for exporting the 2 symbols that I had listed (was above).
Dmitry (cc-ed) can decide about INPUT being bool or not
and what problems it has.
---
~Randy
On Wednesday 20 September 2006 13:04, Robin Getz wrote:
> Randy Dunlap said:
> >ISTM that we should at least fix the first 2 (by EXPORTing them).
> >or we don't allow INPUT=m.
> >
> >You want to send a patch?
>
> No problem - which patch do you want? (exporting? or set INPUT to bool?)
>
> I'll send the export later tonight if no objections.
>
Would there be any objections if I commit the patch below so input
could be built as a module?
--
Dmitry
Input: fix building input core as a module
Signed-off-by: Dmitry Torokhov <[email protected]>
---
drivers/char/random.c | 1 +
lib/kobject.c | 1 +
2 files changed, 2 insertions(+)
Index: work/drivers/char/random.c
===================================================================
--- work.orig/drivers/char/random.c
+++ work/drivers/char/random.c
@@ -645,6 +645,7 @@ void add_input_randomness(unsigned int t
add_timer_randomness(&input_timer_state,
(type << 4) ^ code ^ (code >> 4) ^ value);
}
+EXPORT_SYMBOL_GPL(add_input_randomness);
void add_interrupt_randomness(int irq)
{
Index: work/lib/kobject.c
===================================================================
--- work.orig/lib/kobject.c
+++ work/lib/kobject.c
@@ -119,6 +119,7 @@ char *kobject_get_path(struct kobject *k
return path;
}
+EXPORT_SYMBOL_GPL(kobject_get_path);
/**
* kobject_init - initialize object.
On Thu, Sep 21, 2006 at 12:11:25AM -0400, Dmitry Torokhov wrote:
> Would there be any objections if I commit the patch below so input
> could be built as a module?
>
> --
> Dmitry
>
> Input: fix building input core as a module
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
Acked-by: "Theodore Ts'o" <[email protected]>
- Ted
On Thu, Sep 21, 2006 at 12:11:25AM -0400, Dmitry Torokhov wrote:
> On Wednesday 20 September 2006 13:04, Robin Getz wrote:
> > Randy Dunlap said:
> > >ISTM that we should at least fix the first 2 (by EXPORTing them).
> > >or we don't allow INPUT=m.
> > >
> > >You want to send a patch?
> >
> > No problem - which patch do you want? (exporting? or set INPUT to bool?)
> >
> > I'll send the export later tonight if no objections.
> >
>
> Would there be any objections if I commit the patch below so input
> could be built as a module?
>
> --
> Dmitry
>
> Input: fix building input core as a module
>
> Signed-off-by: Dmitry Torokhov <[email protected]>
No objection from me, feel free to add:
Signed-off-by: Greg Kroah-Hartman <[email protected]>
to this patch.
thanks,
greg k-h
On Thu, Sep 21, 2006 at 12:11:25AM -0400, Dmitry Torokhov wrote:
> On Wednesday 20 September 2006 13:04, Robin Getz wrote:
> > Randy Dunlap said:
> > >ISTM that we should at least fix the first 2 (by EXPORTing them).
> > >or we don't allow INPUT=m.
> > >
> > >You want to send a patch?
> >
> > No problem - which patch do you want? (exporting? or set INPUT to bool?)
> >
> > I'll send the export later tonight if no objections.
> >
>
> Would there be any objections if I commit the patch below so input
> could be built as a module?
Under what circumstances is it desirable to allow INPUT=m ?
I'm having a hard time thinking of a usage scenario where it makes sense.
Dave
On Thu, Sep 21, 2006 at 03:38:56PM -0400, Dmitry Torokhov wrote:
> > Under what circumstances is it desirable to allow INPUT=m ?
> > I'm having a hard time thinking of a usage scenario where it makes sense.
>
> Not normally, no. But for example NSLU2 has a beeper and I believe it
> is the only user of input core there. If you were doing a distribution
> for such device you might want to build both input core and speaker
> driver as modules and let user decide if he wants to thoad them or
> not.
Wow. That's a ton of code to be pulling in just to enable a beeper.
I wonder how many lines a non-input-layer variant of pcspkr.c would be.
It always seemed odd to me that a beeper is an input device anyway.
> Does it being a module hurt anything?
Addition of two more exports for an arguably questionable purpose.
Dave
Dave Jones pondered:
>Under what circumstances is it desirable to allow INPUT=m ?
I know there are some people using it in their embedded product. I don't
exactly know _why_, but last time I checked it was to ensure that the
kernel was as small as possible - which reduces boot time, and their kernel
flash footprint (kernel and file system are seperate).
The input subsystem is one of the last to be initialized in their system,
so it allows a little more flexibility in their overall system design.
-Robin