drivers/char/random.c exported interfaces

drivers/char/random.c exported interfaces

[Robin Getz]

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

Re: drivers/char/random.c exported interfaces

[Randy.Dunlap]

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

Re: drivers/char/random.c exported interfaces

[Robin Getz]

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

Re: drivers/char/random.c exported interfaces

[Randy.Dunlap]

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

Re: drivers/char/random.c exported interfaces

[Dmitry Torokhov]

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 <dtor@mail.ru>
---

 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.

Re: drivers/char/random.c exported interfaces

[Theodore Tso]

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 <dtor@mail.ru>

Acked-by: "Theodore Ts'o" <tytso@mit.edu>

						- Ted

Re: drivers/char/random.c exported interfaces

[Greg KH]

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 <dtor@mail.ru>

No objection from me, feel free to add:
	Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

to this patch.

thanks,

greg k-h

Re: drivers/char/random.c exported interfaces

[Dave Jones]

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

Re: drivers/char/random.c exported interfaces

[Dave Jones]

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

Re: drivers/char/random.c exported interfaces

[Robin Getz]

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