Re: [patch 03/13] input: make input a multi-object module

[Anssi Hannula]

Andrew Morton wrote:
> Anssi Hannula <anssi.hannula@xxxxxxxxx> wrote:
> 
>>Andrew Morton wrote:
>>
>>>Anssi Hannula <anssi.hannula@xxxxxxxxx> wrote:
>>>
>>>
>>>>>>>It would be much nicer all round if we could avoid renaming this file.
>>>>>>
>>>>>>Indeed... There are these 4 options as far as I see:
>>>>>>
>>>>>>1. Do this rename
>>>>>>2. Put all the code in input-ff.c to input.c
>>>>>>3. Make the input-ff a separate bool "module" and add
>>>>>>EXPORT_SYMBOL_GPL() for input_ff_event() which is currently the only
>>>>>>function in input-ff.c that is called from input.c
>>>>>>4. Rename the input "module" to something else, it doesn't matter so
>>>>>>much as almost everybody builds it as built-in anyway.
>>>>>>
>>>>>>WDYT is the best one?
>>>>>
>>>>>
>>>>>I still don't know what problem you're trying to solve so I cannot say.
>>>>
>>>>Maybe you know now.
>>>
>>>
>>>yup, thanks.
>>>
>>>I'd have thought that 3) is the path of least resistance.
>>>
>>>But it does require that input.c "knows" that input-ff.c was included in
>>>the build, which is not a thing we like to do.
>>
>>Well, it's going to be included as built-in and can't be built as a
>>module at all, so I think it's okay for us to do so?
> 
> 
> If that's the case then no EXPORT_SYMBOL_GPL() is needed - we just link the
> the two .o files together, link the result into vmlinux?
> 

Probably so, I was under the false assumption that even built-in modules
should use EXPORT_SYMBOL.

>>>Why should things in input.c call into input-ff.c, btw?  The way we
>>>normally would handle that is to add a register_something() API to input.c
>>>and input-ff.c would insert its callback via that interface.
>>
>>Yes, we could easily add a callback to e.g. struct input_dev, but is
>>that really preferred if the input-ff.c is built-in?
> 
> 
> Nope, not if they're as tightly-coupled as that.

Actually, they don't call each others functions at all (except for the
one we discuss below)... But if input-ff.o would be allowed as a module,
device drivers would either need to know at the build time if input-ff.o
is enabled (not an option, as it could be built as a module afterwards),
_or_ query input.o if the input-ff.o is registered in. However the
latter causes again the situation that nothing depends on input-ff.o and
it is never loaded...

> However it still might not be _appropriate_ for the input core code to call
> into the force-feedback code in this manner.  It certainly sounds unusual.
> 

I guess I could just use the normal event() handler in input_dev:
FF-capable input-drivers should assign input_ff_event() as the event()
or call input_ff_event() in their own event() handler.

Hmm, just came to me mind that input.o can be built as module if
EMBEDDED is set. But input-ff.o doesn't actually require input.o (it's
just not useful without it), so input-ff.o as a built-in wouldn't be a
problem. That's why I wanted them to be in a single module (so that if
input.o is a module, input-ff.o would also be part of that module
instead of being built-in). But I don't think there is someone who runs
with EMBEDDED enabled, INPUT as a module, INPUT_FF_EFFECTS enabled, and
doesn't like that input-ff.o cannot be built as a module.

So, I guess we go for a separate input-ff.o as a bool.

Unless you have any more thoughts, I'll make patches for (1) separate
input-ff.o from input.o so that input.c renaming is not required, and to
(2) use the input_dev->event() handler instead of input.o calling
input-ff.o.

-- 
Anssi Hannula

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/